[Numpy-discussion] numpy.int32, type inheritance and tp_flags

[Charles R Harris]

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
> original
> >     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.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20090602/617abda9/attachment.html>