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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
