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 from bool in Python (which is itself a subclass of int, whereas bool_ 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.
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.
In my experience, mypy + pydantic is a recipe for success, especially for large python projects
I wholeheartedly agree. The ability to describe (in code) and validate all data, from config files to each and every message being exchanged is invaluable.
I’m actively looking for alternatives in other languages now.
You’re just describing parsing in statically-typed languages, to be honest. Adding all of this stuff to Python is just (poorly) reinventing the wheel.
Python’s a great language for writing small scripts (one of my favorite for the task, in fact), but it’s not really suitable for serious, large scale production usage.
What years of dynamic typing brainrot does to mf
I currently work on a NodeJS/React project and apparently I’m going to have to start pasting “‘any’ is not an acceptable return or parameter type” into every damned PR because half the crazy kids who started programming in JavaScript don’t seem to get it.
For fucks sake, we have TypeScript for a reason. Use it!
if you have a pipeline running eslint on all your PRs (which you should have!), you can set no-explicit-any as an error in your eslint config so it’s impossible to merge code with any in it
Type checker detecting different types?
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.
That is a very solid point. If user-defined types are NOT explicitly defined as compatible (supposing language support), they should not be.
In your example, if it were, say a banking system, allowing both types to be considered equivalent is just asking for customer data leaks.
