| From: | David Blewett <david(at)dawninglight(dot)net> |
|---|---|
| To: | James William Pye <lists(at)jwp(dot)name> |
| Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, jd(at)commandprompt(dot)com, Josh Berkus <josh(at)agliodbs(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: plpython3 |
| Date: | 2010-01-17 22:15:47 |
| Message-ID: | 9d1f8d831001171415v2f78b339o3f071a6280c763dd@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Jan 17, 2010 at 4:07 PM, James William Pye <lists(at)jwp(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2010-01-17 23:22:27 | Re: Patch: Remove gcc dependency in definition of inline functions |
| Previous Message | Jeff Davis | 2010-01-17 22:03:00 | is this a bug? |