[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4