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.