Handling of dtype bool is not straight-forward

[Mereep]

I would expect a numpy array containing boolean values to react meaningful to "is True"

Reproducing code example:

import numpy as np
np.array([True])[0] is True
Out[3]: False
np.array([True])[0] == True
Out[4]: True

dtype evaluates to dtype('bool').

I know that the dtype is not build-in anymore, and technically it does not "point to the same object" but I see no reason why numpy should not gracefully handle that situation and do what the user obviously wants to do there.

[pv]

>>> type(np.array([True])[0])
<class 'numpy.bool_'>

The behavior is intentional and will not be changed.
If you want to cast to Python object, do

>>> np.array([True])[0].item() is True
True

[Mereep]

@pv Thanks for the fast response. Just for my personal interest: Was there a discussion about that matter?
And is there a reason why:

np.array([True])[0] is np.array([True])[0]
Out[53]: True
np.array([1])[0] is np.array([1])[0]
Out[54]: False

while

id(np.array([1])[0]) == id(np.array([1])[0]) Out[55]: True

[pv]

The general design of numpy is 10+ years old, and it is now mostly fixed in stone due to backward compatibility.
That's before my time, so I don't know the details how it was arrived at.

The answer to your second question is that only few Python objects are singletons.
For example,

>>> x = 123456789
>>> y = 123456789
>>> x is y
False

[eric-wieser]

The result is a singleton, but it's np.True_ not True.

Your id weirdness with integers is because the first integer is destroyed before you allocate the second, so the second ends up being allocated in the same place.

[Mereep]

Your id weirdness with integers is because the first integer is destroyed before you allocate the second, so the second ends up being allocated in the same place.

Okay that clears up a bit, thanks. I just got curious now and I played it a bit and noticed numerous odd behaviours

(This gets off offtopic for numpy related)

# Ok This is now clear due to object gets destroyed and next reassigns same id ####
id(np.array([1])[0]) == id(np.array([1])[0])

But why

x = 10
y = 10
id(x) == id(y)
Out[145]: True
x is y
Out[146]: True

vs:

x = 123456789
y = 123456789
id(x) == id(y)
Out[149]: False
x is y
Out[150]: False

Okay I played a bit further: x is y is True until 2^8. So Python seems to store objects up to 1 Byte like singletons and handles them different from integers, while type() would always output int.

Wow, learned something today :-) althought I think Python should do this transparent, having the is-keyword behaving consistently for same data type

Considering to report that.

[eric-wieser]

More information on integer caching in python, which is obviously by design.

The is operator in python simply means "these are the same instances of the object" - the language makes no guarantees about whether two integers are identical or different instances. I don't think there's anything to report here.

[Mereep]

Well... I see the point but don't get my wrong: This looks broken by design to me. Since this fact is absolutely invisible, just an optimization, I don't want to see the arbitary side effect of it (And I am sure 99.9% of Python-Users are not aware of that). I see 2x same data type, 2x the same operation, but get 2x a different result. type(10) should evaluate to "const short_10" or something like that.

Anywas thanks for the link and the time 👍