[Python-Dev] Semantics of int(), index() (original) (raw)

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 tied 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 later points out, returning int-subclasses from index() should still work for 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.

Cheers, Nick.

(Bug 17576 would still be a bug in this scenario, since obj.index() still 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 base >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: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com -------------- 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