On 12/26/2010 7:15 PM, Nick Coghlan wrote: > Starting in Python 3.2, range() supports fast containment checking for > integers (i.e. based on an O(1) arithmetic calculation rather than an > O(N) iteration through the entire sequence). > > Currently, this fast path ignores objects that implement __index__ - > they are relegated to the slow iterative search. > > This seems wrong to me - the semantics of __index__ are such that it > is meant to be used for objects that are alternative representations > of the corresponding Python integers (e.g. numpy scalars, or integers > that use a particular number of bits in memory). Under that > interpretation, if an object provides __index__, we should use the > fast path instead of calling __eq__ multiple times. If I understand, you are proposing 'replacing' o with o.__index__() (when possible) and proceeding on the fast path rather than iterating the range and comparing o for equality each value in the range (the slow path). I suppose this would change semantics if o != o.__index__(). Equality is not specified in the manual: "object.__index__(self) Called to implement operator.index(). Also called whenever Python needs an integer object (such as in slicing, or in the built-in bin(), hex() and oct() functions). Must return an integer." However "operator.__index__(a) Return a converted to an integer. Equivalent to a.__index__()." comes close to implying equality (if possible). What are the actual used of .__index__? -- Terry Jan Reedy
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