Python 3.1 support
in [PgSql]
|
Prev: New VACUUM FULL
Next: Aggregate ORDER BY patch
From: Peter Eisentraut on 20 Nov 2009 01:04 On tor, 2009-11-19 at 13:43 -0500, Tom Lane wrote: > But in any case, my main concern here is that I don't want to have > to predetermine which python version a user of Red Hat/Fedora will > have to use. If they can only use one at a time, that's still a > good bit better than not having a choice at all. By the way, mod_wsgi supports Python 3 already (same patch as here, in principle). From the Fedora wiki page, I gather that no one has really looked into packaging that yet for Python 3, but if someone does, maybe we can cross-inspire ourselves. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 20 Nov 2009 02:02 On tor, 2009-11-19 at 13:12 -0700, James Pye wrote: > > I think of a PL/Python function as a Python script file stored > > in the database. > > For Python, I think that's a mistake. Python scripts are independent applications. Is there any precedent for the sort of behavior that you are implementing, that is, automatic sharing of variables between independent executions of the same source container? -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: James Pye on 20 Nov 2009 03:20 On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote: > Is there any precedent for the sort of behavior that you are > implementing, that is, automatic sharing of variables between > independent executions of the same source container? import foo # bar is a regular, def'd function. foo.bar() .... # even in another thread, doesn't matter.. foo.bar() In either call, foo.bar()'s globals() is the same dictionary object(the foo module's dictionary). A plpython3 function *is* a Python module. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Peter Eisentraut on 20 Nov 2009 03:26 On fre, 2009-11-20 at 01:20 -0700, James Pye wrote: > On Nov 20, 2009, at 12:02 AM, Peter Eisentraut wrote: > > Is there any precedent for the sort of behavior that you are > > implementing, that is, automatic sharing of variables between > > independent executions of the same source container? > > import foo > > # bar is a regular, def'd function. > foo.bar() > > ... > > # even in another thread, doesn't matter.. > foo.bar() > > > In either call, foo.bar()'s globals() is the same dictionary object(the foo module's dictionary). That's not what I meant, because this is the same execution of the same source container, with threads explicitly started somewhere. You could do the same in a plpython function (in theory, at least). What I mean is more like, you execute the same source file twice in a row, and the global variables are saved for the second run. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: James Pye on 20 Nov 2009 03:59
On Nov 20, 2009, at 1:26 AM, Peter Eisentraut wrote: > because this is the same execution Hrm, not necessarily. foo could be imported by another, completely independent part of the program. foo is cached in sys.modules. bar() is executed and it's still the same globals(). shared. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |