Michael Hudson wrote:
> David Hopwood <david.nospam.hopwood at blueyonder.co.uk> writes:
>
>> Armin Rigo wrote:
>>> Hi,
>>>
>>> There is an oversight in the design of __index__() that only just
>>> surfaced :-( It is responsible for the following behavior, on a 32-bit
>>> machine with >= 2GB of RAM:
>>>
>>> >>> s = 'x' * (2**100) # works!
>>> >>> len(s)
>>> 2147483647
>>>
>>> This is because PySequence_Repeat(v, w) works by applying w.__index__ in
>>> order to call v->sq_repeat. However, __index__ is defined to clip the
>>> result to fit in a Py_ssize_t.
>> Clipping the result sounds like it would *never* be a good idea. What was
>> the rationale for that? It should throw an exception.
>
> Why would you expect range(10)[:2**32-1] and range(10)[:2**32] to do
> different things?
In that case, I believe it is the slice object that should be suppressing the
overflow error (via PyErr_Occurred and PyErr_Matches) when calculating the
indices for a given length, rather than having silent clipping be part of the
basic implementation of long.__index__().
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://www.boredomandlaziness.org
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