On Tue, 17 Nov 2015 16:23:40 +0100 Christoph Zwerschke <[email protected]> wrote: > great to see you working on Python 3 porting. It's something I also > wanted to tackle, but did not find enough time so far.
Same here but I was afraid that if I didn't dive in that it would never happen. > However, I noticed the port currently creates a lot of backward > incompatibility. The main issue that now under Python 2 we get longs > instead of ints, and unicode instead of str. That will certainly > break a lot of old code that is using PyGreSQL. Should I have switched everything to bytes? There is no string type any more. > You probably did not run the test_pg.py module which tests the > classic module in detail. The other tests are much scarcer and are > not sufficient to guarantee that we stay backward compatible. I forgot about that one. Can we move those tests into one of the others? Alternatively, can we rename is to TEST_PyGreSQL_core.py so that it is grouped with the others on a directory listing? In any case, I want to make a few changes to that. The other two have a mechanism for finding the database for connecting. This one just assumes template0 on the local machine. > Os is that different behavior in Python 2by intent? My understanding > is that the new version should be fully backward compatible and > behave exactly the same under Python 2. I am not sure if we should use Unicode more in 3. However, I think I will revert that change for now and possibly add macros later if we want to change it in 3. > Also, I would like to create a maintenance branch in SVN for the > current version, split off from r522 before you started to make > changes for modern Python. That branch could then be used to create > bugfix or maintenance releases for older Python and Postgres > versions. For the trunk we could then make more modern requirements > like Python 2.7 or change other things that simplify a unified Python > 2+3 version. A lot of the changes were preferred for 2.7 anyway but it's true that they may cause problems before that. > In http://trac.vex.net:8000/pgtracker/roadmap we wanted to release > the Python 2+3 version as 5.0, is that still the plan? The trunk > would then represent "5.x" and I would create the maintenance branch > as "4.x". Yes. I was going to make that change to the build files at some point. > I see two problematic changesets: r526 where you make changes > regarding int/long, and r534, where you make changes regarding > str/unicode. I will revert the str/unicode changes. It's just a search and replace. Maybe I'll make a macro for <3. > In r526 you replaced occurrences of PyInt with PyLong. That means > things like OIDs are returned as longs instead of ints in Python 2 > which makes no sense for OIDs, since they are always 32 bit, and it > breaks the old behavior. Is there anywhere, other than the tests, that this would actually break anything? > My suggesting here is that instead of setting > > #ifndef IS_PY3K > #define PyLong_FromLong PyInt_FromLong > #endif > > and changing all the code, we should do it the other way around: > > #ifdef IS_PY3K > #define PyInt_FromLong PyLong_FromLong > #endif I like the first one because PyInt_FromLong is deprecated anyway and at some point we can just drop the macro. I can just imagine twenty years from now someone scratching their head over why we used PyInt_FromLong and a macro to rename it to a real function. :-) > plus a few more of this kind, and then we can leave the code as it > was. The code will then happily return ints in both Python 2 and > Python 3, which will continue to be real ints in Python 2 and ints of > the unified type in Python 3. Everything stays backward compatible. Of course they aren't really ints. > Regarding r534, it's more problematic. I'll look into it, but want to > get your feedback first. I'm switching everything to bytes. > >> Closer to Python 3. This compiles under both Python 2 and 3 but > >> unit tests dump core under 3. I am getting a bit closer to this. What I have found so far is that the tp_getattro function is called with a non-string. Digging deeper now. -- D'Arcy J.M. Cain PyGreSQL Development Group http://www.PyGreSQL.org IM:[email protected] _______________________________________________ PyGreSQL mailing list [email protected] https://mail.vex.net/mailman/listinfo.cgi/pygresql
