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 thi
On Mon, Dec 14, 2009 at 1:42 PM, Peter Eisentraut 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, because of
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 thi
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-leve
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 igno
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 Postgre
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 pg
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?
>
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 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
implem
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
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/Pyth
Peter Eisentraut 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 globally visible.
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
On ons, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
> "Joshua D. Drake" 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 choos
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
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 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, a
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 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 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 *wi
> 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 proc
"Joshua D. Drake" 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 reasonable if we c
On Wed, 2009-11-18 at 12:28 -0500, Tom Lane wrote:
> "Joshua D. Drake" 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 choos
"Joshua D. Drake" 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 disaster.
> Agr
On Wed, 2009-11-18 at 12:06 -0500, Tom Lane wrote:
> Nathan Boley 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. Tha
Nathan Boley 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 upthread. I'm not
a P
> 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 be
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 develop
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) w
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 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
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 break
On tor, 2009-11-12 at 16:06 -0500, Tom Lane wrote:
> Peter Eisentraut 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 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
Peter Eisentraut 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 separate PL so it
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 needed to create an arguably weird hack to manage the regression
tests. Instead of creating a new expected file for pretty much eve
37 matches
Mail list logo
