Re: plpython3
David Blewett <david@dawninglight.net>
From: David Blewett <david@dawninglight.net>
To: James William Pye <lists@jwp.name>
Cc: Greg Smith <greg@2ndquadrant.com>, Peter Eisentraut <peter_e@gmx.net>, jd@commandprompt.com, Josh Berkus <josh@agliodbs.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL-development Hackers <pgsql-hackers@postgresql.org>
Date: 2010-01-17T22:15:47Z
Lists: pgsql-hackers
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye <lists@jwp.name> wrote: > The effect of this is that every time the FUNCTION is called from PG, the import statements are ran, a new class object, UrlOpener, is created, and a new function object, translate, is created. Granted, a minor amount of overhead in this case, but the point is that in order to avoid it the author would have to use SD: > > if "urlopener" in SD: > UrlOpener = SD["urlopener"] > else: > class UrlOpener(urllib.UrlOpener): > ... > SD["urlopener"] = UrlOpener > > While some may consider this a minor inconvenience, the problem is that *setup code is common*, so it's, at least, a rather frequent, minor inconvenience. > > > With function modules, users have a module body to run any necessary setup code. Coming from a Python developer perspective, this is indeed an improvement. I always thought the whole SD/GD thing was a little odd. Doing the setup at the module level and relying on the interpreter to keep it cached is much more "Pythonic" and is a common idiom. David