Python 3.1 support
in [PgSql]
|
Prev: New VACUUM FULL
Next: Aggregate ORDER BY patch
From: James Pye on 18 Nov 2009 15:36 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 *without some significant refactoring*, any patch fully implementing tracebacks is going to be a seriously ugly hack. What helped the implementer here would help the user. > As far > as I can tell, it just creates more typing for no benefit whatsoever. "def main(*args):" is annoying, but not entirely lamentable... It's explicit, as well(no need to document munging that occurs behind the scenes). Also, compare the cases where you need to cache some initialized data: if 'key' not in SD: ... SD['key'] = my_newly_initialized_data .... With function modules, SD is not needed as you have your module globals to keep your locally cached data in: .... data = my_newly_initialized_data def main(*args): ... > Also, it's inconsistent with normal Python script files Hinges on whether "normal" is actually normal. I often use the __name__ convention in script files myself: if __name__ == '__main__': main(...) That is, using that convention, the script can be import'd and used without executing the "script functionality". (It has proven to be very handy a few times now) > and with other PLs. I don't understand why that's a significant enough interest to note. > I don't need another PostgreSQL implementation on top of Python. Indeed, and I do understand that. That is, I have removed some features with that very thought in mind. (OTOH, I consider the date_part properties on datetime types to be special: too likely useful.) [tho, "PostgreSQL implementation"? I think I understand what you were getting at, but..] > The maintenance effort required to keep those two consistent aside. I don't think there are many consistency issues here. What did you have in mind? > 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. Agreed. It would seem quite doomed. At this point, I'm not going to try getting it into PG. (apparent futility and such) -- 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 18 Nov 2009 20:20 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. -- 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 19 Nov 2009 05:05 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 the same problem. Considerable effort has been put in by Python upstream to make the effort manageable. No one in their right mind is going to create two separate source files just because in the future the mythical differences will be too big, when clearly the effort is going into a direction to reduce the differences. If you look into the source file, there is already special code for Python 2.2, 2.3, 2.4, 2.5, 2.6, and now 3.1. The chunk for 3.1 is a bit bigger, but only a bit, and well, that's why it's 3.x and not 2.x. No one has ever suggested, we might need to support Python 2.2 for a long time, let's create a separate source file. I agree, there will probably need to be some configuration/build support on top of this, but that's something we should work out independently of how to manage the source file. -- 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 19 Nov 2009 05:12 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 are two different models being proposed here. The first approach, which is currently implemented (and some patches pending), is to convert a PostgreSQL type to the "nearest" Python type. For example, text to string, int to int, array to list, timestamp to datetime.datetime, etc. 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. > 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.*? Yeah, see later discussion about how to resolve this. But I think in practice, unless you use lots of print statements in your stored procedures (?!?), this problem is exaggerated. -- 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 19 Nov 2009 07:00
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 write a type converter for bytea -> the > python 3 byte type would the expectation be that I ensure that it > works in Python 2? Or is an ifdef that ignores it in the case of > Python 2 OK, and we can just put a note in the docs. Note that this is already implemented. The main point of the patch is to provide a small compatibility layer so that these kinds of issues are practically nonexistent. The fact that you didn't notice might prove that the patch does its job. ;-) > Also, how far back do we want to maintain 2.x compatibility? 2.0? We handle this on an ad hoc basis. We currently support Python 2.2 and later, and this cutoff exists -- this is my interpretation of history -- because 2.2 introduced iterators and no one bothered(?) to put ifdefs around the code in PL/Python that provides iterator support. Over the years, we will probably drop support for other older Python versions, but there is no process or plan for that. Right now, the support for Python 2.2 is about three lines, so it's not a bother, but when someone comes and implements a major feature that, say, requires Python 2.3, we can probably drop 2.2. But when the major feature requires 2.6, we probably don't want to drop 2.5 quite yet at this time. It's a judgment call. > If I > wanted to submit a patch that makes use of the list sort method, do I > need to ensure that it can either use the cmp arguments or a key > argument? Any patch one is likely to submit will be a C patch, not a Python patch. But anyway, the "key" argument was introduced in Python 2.4, and so we'd have to come to a decision in the community about whether Python 2.3 support is worth keeping versus the value of that new feature. See above. But anyway, this problem has nothing to do with my patch; it has already existed in the same form forever. > What if I wanted to implement a set returning function that made use > of an iterators next() method. Would I just put ifdefs around the code > or a preprocessor definition that defines NEXT as next() for Python > 2.x and __next__() for 3.x? Again, you would likely submit a C patch, and the iterator API is the same between 2.x and 3.x. > I guess that my first impression is that Python broke compatibility > for a reason, and that either plpython can't evolve, or it will > quickly become impossible to maintain. I think this is an exaggeration of reality. Python 3 removed deprecated features. There is a perfectly good migration path that covers most code: Switch to Python 2.6, switch to the new features, remove the old features, switch to Python 3.x. This applies both on the Python and the C level. They did not break compatibility with the intention of making every module author out there reimplement their thing from scratch. Otherwise Python 2.6 would make very little sense at all. Take a look at an example closer to home: PostgreSQL breaks C API compatibility in almost every major release. We do this to remove cruft and support new features. The intent is not to make Slony and PostGIS and all the other modules reimplement their product from scratch every time. They put in a few ifdefs, sometimes they complain about it ;-), and then the problem is solved. > That being said, I mostly buy > the maintenance arguments from the previous discussion, but if we want > to have plpython and plpython3, a bunch of defines and ifdefs does not > seem like the best way to do this. These ifdefs were not my idea. They are in some cases directly and in some cases in spirit from the Python 2.6 header files, so they are the official way to do this. > Would a better approach be to maintain compatibility layer? ie > plython_compat.h/c > plython2.c > plython3.c > > Then patches that apply to a python3 can be applied to plython3.c and > any changed function can be ripped out of plython_compat and moved > into plpython2. As I tried to explain above, we have always had a rolling feature model of sorts, even across various Python 2.x versions. If you want to try it out, you could take the current source and split it up into plpython22.c, plpython23.c, etc. and see if that becomes useful. -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |