[Python-Dev] Range contains and objects with index methods (original) (raw)
Terry Reedy tjreedy at udel.edu
Mon Dec 27 02:52:23 CET 2010
- Previous message: [Python-Dev] Range __contains__ and objects with __index__ methods
- Next message: [Python-Dev] Range __contains__ and objects with __index__ methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Range __contains__ and objects with __index__ methods
- Next message: [Python-Dev] Range __contains__ and objects with __index__ methods
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]