[Numpy-discussion] Python 3 and isinstance(np.int64(42), int)

Post by Jens JÃ¸rgen Mortensen

On Wed, Jun 17, 2015 at 10:53 PM, Jens Jørgen Mortensen

type(n)

isinstance(n, int)

True
With Python 3.4 you get False. I think I understand why (np.int64 is no
longer a subclass of int).

Yep, that's correct.

Post by Jens JÃ¸rgen Mortensen
import numbers
isinstance(n, numbers.Integral)
which works fine (with numpy-1.9). Is this the "correct" way or is
there a better way to do it?

That's the correct way to check whether an arbitrary object is of some
integer-like-type, yes :-). There are alternatives, and there's some
argument that in Python, doing explicit type checks like this is
usually a sign that one is doing something awkward, but that's a more
general issue that it's hard to comment on here without more detail
about what exactly you're trying to accomplish.

Post by Jens JÃ¸rgen Mortensen
I would imagine that a lot of code will
break because of this - so it would be nice if isinstance(n, int) could
be made to work the same way in 2 and 3, but I don't know if this is
possible (or desirable).

It's not possible, unfortunately. In py2, 'int' is a 32- or 64-bit
integer type, so we can arrange for numpy's int32 or int64 objects to
be laid out the same in memory, so everything in python that expects
an int (including C API functions) can handle a numpy int. In py3,
'int' is an arbitrary width integer bignum, like py2 'long', which is
fundamentally different from int32 and int64 in both semantics and
implementation.

-n

--
Nathaniel J. Smith -- http://vorpus.org

Sebastian Berg

2015-06-18 08:38:43 UTC

Post by Jens JÃ¸rgen Mortensen

In some cases calling operator.index(n) may yield the desired result. I
like operator.index, but maybe it is just me :). That uses duck typing
instead of instance checking to ask if it represents an integer.
But it also has some awkward corner cases in numpy, since arrays with a
single element (deprecation pending) and 0D arrays (will continue) say
they are integers when asked that way.

- Sebastian

On Wed, Jun 17, 2015 at 10:53 PM, Jens JÃžrgen Mortensen

type(n)

isinstance(n, int)

True
With Python 3.4 you get False. I think I understand why (np.int64 is no
longer a subclass of int).

Yep, that's correct.

Post by Jens JÃ¸rgen Mortensen
import numbers
isinstance(n, numbers.Integral)
which works fine (with numpy-1.9). Is this the "correct" way or is
there a better way to do it?

Sturla Molden

2015-06-18 11:55:46 UTC

Post by Nathaniel Smith
In py3,
'int' is an arbitrary width integer bignum, like py2 'long', which is
fundamentally different from int32 and int64 in both semantics and
implementation.

Only when stored in an ndarray.

An array scalar object does not need to care about the exact number of bits
used for storage as long as the storage is large enough, which a python int
always is.

Sturla

Chris Barker

2015-06-19 20:15:26 UTC

Post by Nathaniel Smith
there's some
argument that in Python, doing explicit type checks like this is
usually a sign that one is doing something awkward,

I tend to agree with that.

On the other hand, numpy itself is kind-of sort-of statically typed. But in
that case, if you need to know the type of an array -- check the array's
dtype.

a = np.zeros(7, int)
n = a[3]
type(n)

<type 'numpy.int64'>

I Never liked declaring numpy arrays with the python types like "int" or
"float" -- in numpy you usually care more about the type, so should simple
use "int64" if you want a 64 bit int. And "float64" if you want a 64 bit
float. Granted, pyton floats have always been float64 (on all platfroms??),
and python ints used to a be a reasonable int type, but now that python
ints are bigInts in py3, it really makes sense to be clear.

And now that I think about it, in py2, int is 32 bit on win64 and 64 bit on
*nix64 -- so you're really better off being explicit with your numpy arrays.

-CHB
--
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

***@noaa.gov

j***@gmail.com

2015-06-23 16:33:11 UTC

Post by Nathaniel Smith
there's some
argument that in Python, doing explicit type checks like this is
usually a sign that one is doing something awkward,

I tend to agree with that.
On the other hand, numpy itself is kind-of sort-of statically typed. But
in that case, if you need to know the type of an array -- check the array's
dtype.

a = np.zeros(7, int)
n = a[3]
type(n)

<type 'numpy.int64'>
I Never liked declaring numpy arrays with the python types like "int" or
"float" -- in numpy you usually care more about the type, so should simple
use "int64" if you want a 64 bit int. And "float64" if you want a 64 bit
float. Granted, pyton floats have always been float64 (on all platfroms??),
and python ints used to a be a reasonable int type, but now that python
ints are bigInts in py3, it really makes sense to be clear.
And now that I think about it, in py2, int is 32 bit on win64 and 64 bit
on *nix64 -- so you're really better off being explicit with your numpy
arrays.

being late checking some examples

a = np.zeros(7, int)
a.dtype

dtype('int32')

np.__version__

'1.9.2rc1'

type(a[3])

a = np.zeros(7, int)
a = np.array([888888888888888888])
a

array([888888888888888888], dtype=int64)

a = np.array([888888888888888888888888888888888])
a

array([888888888888888888888888888888888], dtype=object)