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__.
Hmm.
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.
operator.index(a)
operator.__index__(a)
Return a converted to an integer. Equivalent to a.__index__().
bin(x)
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):
... pass
...
>>> range(10)[myint(2):myint(3)]
range(2, 3)
Same goes for hex/oct/bin:
>>> hex(myint(4))
'0x4'
>>> bin(myint(4))
'0b100'
>>> oct(myint(4))
'0o4'
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
>>> type(index(anint(7)))
<class '__main__.anint'>
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
about.
Cheers,
-Barry
signature.asc
Description: PGP signature
_______________________________________________ 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
