(original) (raw)

On 4 Apr 2013 00:18, "Barry Warsaw" <barry@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@python.org
\> http://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: http://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com