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

Robert Kern robert.kern at gmail.com
Wed Apr 3 15:11:18 CEST 2013


On 2013-04-03 13:47, Hrvoje Niksic wrote:
> 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".

We don't.

[~]
|1> type(float(np.float64(1.0)))
float

[~]
|2> type(int(np.int32(1)))
int

-- 
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
  that is made terrible by our own mad attempt to interpret it as though it had
  an underlying truth."
   -- Umberto Eco



More information about the Python-Dev mailing list