[Numpy-discussion] numpy.int32, type inheritance and tp_flags
Charles R Harris
charlesr.harris at gmail.com
Tue Jun 2 02:17:06 EDT 2009
On Mon, Jun 1, 2009 at 11:50 PM, David Cournapeau <
david at ar.media.kyoto-u.ac.jp> wrote:
> Charles R Harris wrote:
> > On Mon, Jun 1, 2009 at 11:08 PM, David Cournapeau
> > <david at ar.media.kyoto-u.ac.jp <mailto:david at ar.media.kyoto-u.ac.jp>>
> > wrote:
> > Hi,
> > I have a question related to #1121
> > (http://projects.scipy.org/numpy/ticket/1121). With python 2.6,
> > PyInt_Check(a) if a is an instance of numpy.int32 does not work
> > anymore.
> > It think this is related to the python issue 2263
> > (http://bugs.python.org/issue2263), where the tp_flags has been
> > changed
> > for the python int object, change which influences PyInt_Check
> > behavior.
> > What should we do about it ? Right now, it looks like the
> > bitfields are
> > harcoded in scalar types - shouldn't we inherit them from the
> > python types (in a field per field manner) instead ?
> > Maybe, but why should it work for int32 anyway?
> Because it does at the Python level ?
> issubclass(np.int32, int) # True
> And some code depends on this (I noticed the problem while tracking down
> some issues for scipy 0.7.x on python 2.6), although the code could be
> modified to not depend on it anymore I guess.
> > IIRC, the python int type has different lengths on windows and linux
> > 64 bit systems.
> Yes, because the underlying C type is a long (at least for python 2.5.4
> as I read it from Include/intobject.h in the sources). Windows (with MS
> compilers at least) reserves 4 bytes only for long on 64 bits.
> But is numpy.int32 really a subclass of int on 64 bits ? I played a bit
> with numpy on python 2.4 64 bits (Linux):
No, IIRC, int64 is. You can see this in the different behavior, i.e., it
doesn't act like the other numpy scalars.
> import numpy as np
> int(2**33) # Returns the right value, of type 'int'
> np.int32(2**33) # Oups, 0
> On 32 bits:
> import numpy as np
> int(2*33) # Returns the right value, of type 'long'
> np.int32(2**33) # 66 ...
> > And what about 3.0?
> There is not python 2.* int anymore, only python 2.* long object (which
> becomes the sole int object on py3k). The PyInt_* apis are gone too,
> starting from 3.1.
Exactly, and that's going to hurt. Macro time ;)
> > I think we probably need to do something here, but I'm not sure what.
> > The different behavior of the numpy double and integer types
> > corresponding to the python types as opposed to the rest of the scalar
> > types is an issue that has annoyed me since forever.
> I think for now I will just add a workaround in scipy.
That's probably the safest thing at the moment.
> I don't
> understand much about scalar types, so I don't have a clue about what to
> do - I feel that it will be one dark area for 3.* porting, though :)
Me too, on all counts.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion