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
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com