[Python-Dev] Range __contains__ and objects with __index__ methods
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. Thoughts? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
Re: [Python-Dev] Range __contains__ and objects with __index__ methods
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
Re: [Python-Dev] Range __contains__ and objects with __index__ methods
What are the actual used of .__index__? Can you please rephrase this question? Regards, Martin ___ 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
Re: [Python-Dev] Range __contains__ and objects with __index__ methods
On Mon, Dec 27, 2010 at 11:52 AM, Terry Reedy tjre...@udel.edu wrote: Return a converted to an integer. Equivalent to a.__index__(). comes close to implying equality (if possible). What are the actual used of .__index__? PEP 357 gives the original rationale - it was to allow integer-like objects (such as numpy scalars) to be used as sequence indices, as well as slice parameters. I would have to grep the source to get a full list of uses, but I believe it is already used in at least those two cases, as well as for sequence repetition (via '*') and to identify permitted inputs to bin/oct/hex. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
