> It is a 64-bit problem, but doesn't have to do with the checkin to > sliceobject. The new test (below) broke with old code too. > > vereq(range(10)[::sys.maxint - 1], [0]) > > The problem is that sizeof(int) != sizeof(long). The parameters for > PySlice_GetIndices() and PySlice_GetIndicesEx() take ints, not longs. > So the code is doing: > > range(10)[::-2] > > since the high 32 bits are lost. > > The only solution I can think of is to have 2 interfaces: > - the old API which takes int/int*, PySlice_GetIndices() > deprecate this API and raise overflow exception > if (int)value != (long)value > - the new API which takes long/long*, PySlice_GetIndicesEx() > > PySlice_GetIndicesEx() was added in 2.3. You meant "must be added" right? > Otherwise, we are stuck with slices only being able to support > 32 bits even on 64 bit architectures. But *everything* having to do with sequences only supports 32 bits: ob_size, PySequence_Length() the arguments to PySequence_GetItem(), etc. Unless you want to fix all those (breaking backwards compatibility), I'm not sure why you'd want to fix PySlice_GetIndices()... --Guido van Rossum (home page: http://www.python.org/~guido/)
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