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.
_______________________________________________
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/archive%40mail-archive.com
