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

Hrvoje Niksic hrvoje.niksic at avl.com
Wed Apr 3 14:47:31 CEST 2013

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.

More information about the Python-Dev mailing list