[Python-Dev] Semantics of __int__(), __index__()
barry at python.org
Wed Apr 3 19:44:06 CEST 2013
On Apr 04, 2013, at 01:14 AM, Nick Coghlan wrote:
>Implementing __index__ just means "This type can be converted to a Python
>integer without losing information". Aside from that extra "without
>information loss" qualification, it's the same as __int__.
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.
Return a converted to an integer. Equivalent to a.__index__().
Convert an integer number to a binary string. The result is a valid Python
expression. If x is not a Python int object, it has to define an
__index__() method that returns an integer.
Certainly, in slicing an int subclass will work fine:
>>> class myint(int):
Same goes for hex/oct/bin:
Also, hex/oct/bin aren't types, they're functions, so this doesn't seem
equivalent to int or str for me. The latter two are much more equivalent to
the built-in tuple, dict, and list types.
So I don't think there's any inconsistency in allowing int subclasses to be
returned from __index__(), and nothing should break, so I see no reason to
change the status quo here.
>>> class anint(int):
... def __index__(self):
... return myint(self)
>>> from operator import index
Aside: It seems a bit odd to me that bin/hex/oct are defined to use
__index__() instead of __int__(), but that's probably not worth arguing
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 836 bytes
Desc: not available
More information about the Python-Dev