[Python-Dev] Semantics of __int__(), __index__()

Nick Coghlan 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
to all
> 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.)
> +1
> -Barry
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20130404/dad48c4e/attachment.html>

More information about the Python-Dev mailing list