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

Steven D'Aprano steve at pearwood.info
Wed Apr 3 18:04:11 CEST 2013

On 04/04/13 01:16, Barry Warsaw 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.

Why must it? I think that's the claim which must be justified, not just taken
as a given.

When we call n = int(something), what's the use-case for caring that n is an
instance of built-in int but not of a subclass, and is that use-case so
compelling that it must be enforced for all uses of int() etc.?

As I see it, what I expect is this:

n = int(something)
assert isinstance(n, int)

not this:

n = int(something)
assert type(n) is int

I haven't cared about checking type identity since "Unifying types and classes" way back in Python 2.2, and I don't see why we should enforce a more restrictive rule now.


More information about the Python-Dev mailing list