[Python-Dev] Semantics of __int__(), __index__()
ncoghlan at gmail.com
Wed Apr 3 17:14:28 CEST 2013
On 4 Apr 2013 00:18, "Barry Warsaw" <barry at python.org> wrote:
> On Apr 03, 2013, at 09:17 PM, Nick Coghlan wrote:
> >Perhaps we should start emitting a DeprecationWarning for int subclasses
> >returned from __int__ and __index__ in 3.4?
> I definitely agree with doing this for __int__(), since it's intimately
> to int(), which is clearly a type conversion operation. It's analogous
> the other built-in types-as-functions, so int() calls __int__() which must
> return a concrete integer.
> __index__() is a bit trickier because it is not tied directly to type
> conversion. In this case, int subclasses could be valid, and as Hrvoje
> points out, returning int-subclasses from __index__() should still work
> all valid use cases.
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__.
> (Bug 17576 would still be a bug in this scenario, since obj.__index__()
> needs to be called by operator.index() even when it's an int subclass.)
> >(I like the idea of an explicit error over implicit conversion to the
> >type, so deprecation of subtypes makes sense as a way forward. We should
> >check the other type coercion methods, too.)
> Python-Dev mailing list
> Python-Dev at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev