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

[Guido van Rossum]

On Tue, Aug 05, 2003 at 09:19:41PM -0400, Tim Peters wrote:
> [Martin]
> > Ah, and I mean <type 'int'>, when I say <type 'integer'> :-)
> 
> In that case, no, Python has no intent of claiming that a Python int can
> hold a machine address.  It does intend that a machine address can be held a
> Python integer, but doesn't promise that such an integer won't be a Python
> long.  So the array buffer_info test is making a bogus assumption (and the
> intended way to repair that was given before).

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.

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

> The other test insisting that id() == hash() for an instance of a
> user-defined class that doesn't define __hash__ is also making a bogus
> assumption, since hash() results are specifically Python ints today while
> id() results are Python integers (ints or longs).  I'm not sure what that
> test was *trying* to check; the test looked pretty useless to me.

WIthout reading the code, agreed.

> I expect that both these tests were introduced after Trent finished the
> Win64 port (test_descr.py certainly came after that port), so simply haven't
> been run on Win64 before.
> 
> If Win64 has a future, I suppose it would be good to repair this stuff; but
> I don't expect any other platform in my lifetime to decide to make
> sizeof(void*) > sizeof(long), so it's tempting to take the lack of previous
> reports of Win64 test failures as evidence about that platform's viability.

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.

--Guido van Rossum