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

[Hrvoje Niksic]

On 04/03/2013 01:17 PM, Nick Coghlan wrote:
>  > > >
>  > > I like Nick's answer to that: int *should* always return something of
>  > > exact type int.  Otherwise you're always left wondering whether you
>  > > have to do "int(int(x))", or perhaps even "int(int(int(x)))", to be
>  > > absolutely sure of getting an int.
>  >
>  > Agreed.
>
> Perhaps we should start emitting a DeprecationWarning for int subclasses
> returned from __int__ and __index__ in 3.4?

Why would one want to be absolutely sure of getting an int?

It seems like a good feature that an __int__ implementation can choose 
to return an int subclass with additional (and optional) information. 
After all, int subclass instances should be usable everywhere where ints 
are, including in C code.  I can imagine numpy and similar projects 
would be making use of this ability already -- just think of uses for 
numpy's subclasses of "float".

If one wants to break the abstraction and be absolutely positively sure 
of getting an int and not a subclass thereof, they can write something 
like (0).__add__(obj).  But I suspect this will be extremely rare.