[Python-Dev] Semantics of int(), index() (original) (raw)
Robert Kern robert.kern at gmail.com
Wed Apr 3 15:11:18 CEST 2013
- Previous message: [Python-Dev] Semantics of __int__(), __index__()
- Next message: [Python-Dev] Semantics of __int__(), __index__()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Previous message: [Python-Dev] Semantics of __int__(), __index__()
- Next message: [Python-Dev] Semantics of __int__(), __index__()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]