Thomas Wouters wrote: > Neal Norwitz wrote: > > minus comments, etc yields several questions about whether some > > values should use Py_ssize_t rather than C longs. In particular: > > > * ints: Include/intobject.h: long ob_ival; > > As Tim says, this is way out of scope for 2.5. Guido said it is ok > to change this to 64-bit ints in 2.6, but I expect some embedded > system developers will start screaming when they hear that: 64-bit > arithmetic is expensive on a 32-bit machine. > > > Well, those systems shouldn't have a 64-bit Py_ssize_t anyway, should they?
No - but Guido said he wanted Python int to have a 64-bit representation everywhere, not a Py_ssize_t representation. I agree using Py_ssize_t would be a "smaller" change, and one that likely has less performance impact. It would still be a large change, and should be only done if we know for sure we don't want it to be a 64-bit type always the next day. Regards, Martin _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
