Explanation: Python is a programming language. Numpy is a library for python that makes it possible to run large computations much faster than in native python. In order to make that possible, it needs to keep its own set of data types that are different from python’s native datatypes, which means you now have two different bool
types and two different sets of True
and False
. Lovely.
Mypy is a type checker for python (python supports static typing, but doesn’t actually enforce it). Mypy treats numpy’s bool_
and python’s native bool
as incompatible types, leading to the asinine error message above. Mypy is “technically” correct, since they are two completely different classes. But in practice, there is little functional difference between bool
and bool_
. So you have to do dumb workarounds like declaring every bool values as bool | np.bool_
or casting bool_
down to bool
. Ugh. Both numpy and mypy declared this issue a WONTFIX. Lovely.
bool_
via Numpy is its own object, and it’s fundamentally different frombool
in Python (which is itself a subclass ofint
, whereasbool_
is not).They are used similarly, but they’re similar in the same way a fork and a spork can both be used to eat spaghetti.
This explanation is pretty clear cut
What exactly is your use case for treating
np.bool_
andbool
as interchangeable? Ifnp.bool_
isn’t a subclass ofbool
according to Python itself, then allowing one to be used where the other is expected just seems like it would prevent mypy from noticing bugs that might arise from code that expects abool
but gets annp.bool_
(or vice versa), and can only handle one of those correctly.mpy and numpy are opensource. You could always implement the fix you need yourself ?
So you have to do dumb workarounds like declaring every
bool
values asbool | np.bool_
or castingbool_
down tobool
.these dumb workarounds prevent you from shooting yourself on the foot and not allowing JS-level shit like
"1" + 2 === "12"
Honestly, after having served on a Very Large Project with Mypy everywhere, I can categorically say that I hate it. Types are great, type checking is great, but applying it to a language designed without types in mind is a recipe for pain.
Adding types on an untyped project is hell. Greenfield stuff is usually pretty smooth sailing as far as I’m concerned…
Well yeah just because they kinda mean the same thing it doesn’t mean that they are the same. I can wholly understand why they won’t “fix” your inconvenience.
Data typing is important. If two types do not have the same in-memory representation but you treat them like they do, you’re inviting a lot of potential bugs and security vulnerabilities to save a few characters.
ETA: The WONTFIX is absolutely the correct response here. This would allow devs to shoot themselves in the foot for no real gain, eliminating the benefit of things like mypy. Type safety is your friend and will keep you from making simple mistakes.
Even if they do have the same in-memory representation, you may want to assert types as different just by name.
AccountID: u64
TransactionID: u64
have the same in-memory representation, but are not interchangeable.
So many people here explaining why Python works that way, but what’s the reason for numpy to introduce its own boolean? Is the Python boolean somehow insufficient?
From numpy’s docs:
The bool_ data type is very similar to the Python bool but does not inherit from it because Python’s bool does not allow itself to be inherited from, and on the C-level the size of the actual bool data is not the same as a Python Boolean scalar.
and likewise:
The int_ type does not inherit from the int built-in under Python 3, because type int is no longer a fixed-width integer type.