[Python-Dev] ssize_t question: longs in header files

Thomas Wouters thomas at python.org
Mon May 29 23:57:37 CEST 2006


On 5/29/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:

> 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.


Well, implementing PyInt in terms of a new symbolic type, even if it
defaults to 64-bit, should make choosing it to be a 32-bit type a lot
easier, shouldn't it?
Not that I think defaulting PyInt to use 'long long' is a good thing,
considering we still only compile 'long long' support optionally. Better to
stick with a common native type until all machines have 64-bit registers.
Better for performance, too.

But switching PyInts to use (a symbolic type of the same size as) Py_ssize_t
means that, when the time comes that 32-bit architectures are rare, Win64
isn't left as the only platform (barring other LLP64 systems) that has slow
33-to-64-bit Python numbers (because they'd be PyLongs there, even though
the platform has 64-bit registers.) Given the timeframe and the impact,
though, perhaps we should just do it -- now -- in the p3yk branch and forget
about 2.x; gives people all the more reason to switch, two years from now.

-- 
Thomas Wouters <thomas at python.org>

Hi! I'm a .signature virus! copy me into your .signature file to help me
spread!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060529/5a5311f3/attachment.html 


More information about the Python-Dev mailing list