Am 20.11.2015 um 18:38 schrieb D'Arcy J.M. Cain:
> Those tests are going to fail when we move to 3.  I guess the trunk
> should always return long and the test should change to reflect that.
> I think that it is not unreasonable to change it for 2.x in 5.x.

I'd really not want to introduce that backward incompatibility.

Let me give several reasons:

* "Never surprise the user!" aka "The principle of least surprise". Python 2 users will not understand why we suddenly return long when int would be the obvious type in Python 2 and there is no reason to change that, except that it may make the life for us as developers a little bit easier.

* I guess I'm not the only one who has legacy code that uses PyGreSQL and really doesn't want to be forced to check whether that code breaks when we suddenly return longs in place where we returned ints before, or unicode where we used to return str. Yes, we still have the maintenance branch, but Linux distributions will probably ship with the trunk anyway, even for Python 2, as only the trunk will see much awaited new features.

* int is the "native" integer type of Python 2. All tests would pass without case distinctions.

* Python 3 has been optimized for long ints, while Python 2 has been optimized for ints. For instance, Python 2 pre-instantiates int objects for all small numbers, but it does not pre-instantiate long objects for small numbers. Python 3 does that.

* There are places like the query() method where return values can have different meaning depending on their type. That's one of the places where users could do an isinstance(rv, int) and things break if we return long instead of int.

* psycopg2 does the same, it returns int in Python2.

* Using py3c it would really be not a big deal to get it right, and I volunteer to do that (will do it right now if you agree). py3c is one file that could be included in the source and could also help in a few other places.

-- Christoph
_______________________________________________
PyGreSQL mailing list
[email protected]
https://mail.vex.net/mailman/listinfo.cgi/pygresql

Reply via email to