Re: WIP: plpython3

On Jul 24, 2009, at 7:08 PM, Stuart Bishop wrote:
> I'm not particularly interested in Python 3.x support yet (we are  
> still back on 2.4, soon to hop to 2.5 or 2.6. For us 3.1 is probably  
> 2 years away at the earliest). I am interested in improved plpython  
> though.

Two years would hopefully be enough time to work out most of the new  
bugs. =)

> This way I can pass in a mock object. This is also useful outside of  
> the test suite - the same module can be used as a stored procedure  
> or by your Python application - your web application can use the  
> same validators as your check constraints for instance.

Hmm.

import sys
sys.modules["Postgres"] = mock_pg_module

Would that not suffice?

> I'd like a way to avoid initialization on module import if possible.  
> Calling an initialization function after module import, if it  
> exists, would do this.
>
> CREATE FUNCTION foo(int) RETURNS in LANGUAGE plpythonu AS
> $python$
> [initialization on module import]
> def pg_init(pg):
>   [initialization after module import]
> def pg_main(pg, i):
>   return i
> $python$;

I do like this idea. However, it may already be possible under the  
current design with some explicit main() management:

CREATE ...
$python$
import Postgres

def usual(*args):   ...

def init(*args):   global main   ...   main = usual   return usual(*args)

main = init
$python$;

Perhaps ugly, but I imagine a construct could be created to clean it up:

CREATE ...
$python$
import Postgres

def usual(*args):   ...

def init(*args):   ...   return usual(*args)

main = call_once_then(init, lambda: globals()['main'] = usual)
$python$;

Hmm, still ugly tho, no?

Well, the above examples aren't actually consistent with your design,  
but perhaps it achieves the desired result?


> I tend to dislike magic function names, but perhaps it is the most  
> usable solution.

Indeed.