[Python-Dev] sizeof(long) != sizeof(void*)

[Tim Peters]

[Guido]
> OK, but in the past (when I was younger :-) *I* thought
> that that was a safe claim, otherwise I wouldn't have implemented
> id() the way it was.  In that past, the difference between Python int
> and long was much greater, since much of the C library code wouldn't
> deal with longs at all.

Well, that's all in the past, and id() isn't implemented that way anymore;
at this time it's just a fact that a Python int isn't big enough to hold a
machine address on all boxes.

> Unfortunately MS broke the assumption that sizeof(void*) <=
> sizeof(long) with its decision to keep long at 32 bits on Win64, and
> there's nothing we can do about it now (except switching int to use a
> long long internally, an idea with which I have played a bit in
> theory but which probably would suck in practice for various stupid
> reasons).

At a time when we're trying to eradicate the user-visible distinction
between ints and longs, making ints bigger seems like a distraction too.

> ...
> An alternative might be to make the type of C integer used to
> implement a Python (short) int a configuration option, using a 64 bit
> int on Win32.
>
> This unfortunately would suffer from various suckage too, as
> convenience functions like PyInt_AsLong() are screwed and can fail in
> ways they could never fail before, likely confusing code that doesn't
> expect them to fail.

Martin is seeing a handful of failing tests on Win84, and so far it sounds
like they're shallow failures and easily fixed.  If we were to fiddle
Python's C code, I'd be more keen to get rid of the assumption that
containers have a number of elements that fits in a C int.  Either way
probably leaks into the signatures in the Python C API.