I wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level coding incompatibilities. It
looks like this patch
On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut pete...@gmx.net wrote:
I wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2,
I wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level coding incompatibilities. It
looks like this patch
On Fri, 2009-12-11 at 01:19 +0200, Peter Eisentraut wrote:
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
There was considerable debate earlier about whether we wanted to treat
Python 3 as a separate PL so it could be available in parallel with
plpython 2, because of the user-level coding incompatibilities. It
looks like this patch simply ignores
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()
...
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
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
Am 19.11.2009 18:01, schrieb James Pye:
On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote:
The other approach, which is what James Pye's
new implementation proposes (as I understand it), is to convert
PostgreSQL types into specially made Python objects, such as
Postgres.types.record or
On ons, 2009-11-18 at 09:48 -0800, Joshua D. Drake wrote:
Although I wonder if longer
term (2.x is going to be support a long time) we will end up with
frustration within the single source file trying to keep things
straight.
There are five million Python modules with C code out there with
On ons, 2009-11-18 at 08:43 -0800, Nathan Boley wrote:
Again, I'm only one user. But so far I haven't seen anyone else speak
up here, and clearly accepting this for inclusion will need nontrivial
convincing.
Well, FWIW, I am excited about better type integration.
Let's clarify, as there
On ons, 2009-11-18 at 11:32 -0800, Nathan Boley wrote:
I took a cursory look at this patch and, while the logic seems sound
and roughly in line with the suggested python porting procedure, I'm
not quite certain what this implies for potential future patches.
For instance, if I wanted to
On Nov 19, 2009, at 3:12 AM, Peter Eisentraut wrote:
The other approach, which is what James Pye's
new implementation proposes (as I understand it), is to convert
PostgreSQL types into specially made Python objects, such as
Postgres.types.record or Postgres.types.timestamp.
Convert is not a
On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Yes. That's exactly what I was complaining about upthread. I'm not
a Python user, but from what I can gather of the 2-to-3 changes,
having
On ons, 2009-11-18 at 13:36 -0700, James Pye wrote:
On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote:
The question is whether it helps the user, not the implementer.
Sure, but do you have a patch waiting to implement tracebacks?
I'd argue the reason it's never been done is due to the
Peter Eisentraut pete...@gmx.net writes:
By the way, it occurred to me that having two different versions of
libpython loaded into the same process is probably not going to work
sanely.
Why not? There's no way they'd even know about each other. We tell
the loader not to make the symbols
On Nov 19, 2009, at 11:32 AM, Peter Eisentraut wrote:
But you wouldn't, for example, get away with breaking SQL (or even
improving it incompatibly) to facilitate a better elog.
This doesn't fit the situation.
I'm not breaking PL/Python. I'm trying to add PL/Python3. =)
I think of a PL/Python
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
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
On sön, 2009-11-15 at 18:39 -0700, James Pye wrote:
I can see how function modules might look like a half-step backwards from
function fragments at first, but the benefits of a *natural* initialization
section (the module body) was enough to convince me. The added value on the
PL
Again, I'm only one user. But so far I haven't seen anyone else speak
up here, and clearly accepting this for inclusion will need nontrivial
convincing.
Well, FWIW, I am excited about better type integration.
Also, I am a little skeptical about this patch. I am sorry if this has
already been
Nathan Boley npbo...@gmail.com writes:
Also, I am a little skeptical about this patch. I am sorry if this has
already been discussed, but would this mean that I need to choose
whether pl/python is built against Python 2.* or Python 3.*?
Yes. That's exactly what I was complaining about
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Nathan Boley npbo...@gmail.com writes:
Also, I am a little skeptical about this patch. I am sorry if this has
already been discussed, but would this mean that I need to choose
whether pl/python is built against Python 2.* or Python 3.*?
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Yes. That's exactly what I was complaining about upthread. I'm not
a Python user, but from what I can gather of the 2-to-3 changes,
having to choose one at package build time is going to be a
On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
Yes. That's exactly what I was complaining about upthread. I'm not
a Python user, but from what I can gather of the 2-to-3 changes,
having
Joshua D. Drake j...@commandprompt.com writes:
On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
Peter was concerned about duplicative maintenance effort, but what I
think this patch shows is that (at least for the near future) both
could be built from a single source file.
That seems
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
I took a cursory look at this patch and, while the logic seems sound
and roughly in line with the suggested python porting
On Nov 18, 2009, at 8:37 AM, Peter Eisentraut wrote:
The question is whether it helps the user, not the implementer.
Sure, but do you have a patch waiting to implement tracebacks?
I'd argue the reason it's never been done is due to the way procedures are
currently managed in PL/Python. And
On Nov 18, 2009, at 1:36 PM, James Pye wrote:
At this point, I'm not going to try getting it into PG. (apparent futility
and such)
ugh, on second thought, I think I've written a bit too much code to stop now.
I'm going to get plpython3 as far as I can and submit it to the next commitfest.
--
On fre, 2009-11-13 at 11:27 -0700, James Pye wrote:
Some are TODOs, so in part by other people. Some were briefly touched
on in the recent past discussions(around the time that I announced the
WIP). Native typing vs conversion, function fragments vs function
modules.
I'm of course only one
On Nov 15, 2009, at 6:37 AM, Peter Eisentraut wrote:
but these two features don't excite me at all,
hrm.. at all?
I can see how function modules might look like a half-step backwards from
function fragments at first, but the benefits of a *natural* initialization
section (the module body)
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
Peter Eisentraut pete...@gmx.net writes:
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
There was considerable debate
On tor, 2009-11-12 at 18:42 -0700, James Pye wrote:
For me, plpython has never been what I would call a pleasure to use,
and many of the gripes that I have with it are, IMO, entrenched far
enough into the implementation that any efforts to change it
would(should? =) cause unacceptable breakage
On Nov 13, 2009, at 4:47 AM, Peter Eisentraut wrote:
Has this list of gripes ever been brought up and discussed in this
forum?
Some are TODOs, so in part by other people. Some were briefly touched on in the
recent past discussions(around the time that I announced the WIP). Native
typing vs
Peter Eisentraut pete...@gmx.net writes:
Here's the patch to support Python =3.1 with PL/Python. The
compatibility code is mostly in line with the usual 2-3 C porting
practice and is documented inline.
There was considerable debate earlier about whether we wanted to treat
Python 3 as a
On Nov 12, 2009, at 12:54 PM, Peter Eisentraut wrote:
Here's the patch to support Python =3.1 with PL/Python.
:\
I was hoping to be able to use Python 3 to draw a clear distinction between
plpython and the would-be plpython3 that I've been working on. I understand
that you're not in favor of
36 matches
Mail list logo
