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.