And do you eat that spaghetti out of a bool?

Adding types on an untyped project is hell. Greenfield stuff is usually pretty smooth sailing as far as I’m concerned…

In my experience, mypy + pydantic is a recipe for success, especially for large python projects

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!

That's actually a quite bad way of naming types, even if someone really insists on using 32 bit integers for bools for "performance" reasons.

I learned Python as my first programming language, but ever since I got into other languages, I don't like going back to dynamic typing...

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.

Unless I'm missing something big here, saying they "kinda mean the same thing" is a hell of an understatement.

The JS thing makes perfect sense though,

"1" is a string. You declared its type by using quotes. myString = "1" in a dynamically typed language is identical to writing string myString = "1" in a statically typed language. You declare it in the symbols used to write it instead of having to manually write out string every single time.

2 is an integer. You know this because you used neither quotes nor a decimal place surrounding it. This is also explicit.

"1" + 2, if your interpreter is working correctly, should do the following

• identify the operands from left to right, including their types.

• note that the very first operand in the list is a string type as you explicitly declared it as such by putting it in quotes.

• cast the following operands to string if they are not already.

• use the string addition method to add operands together (in this case, this means concatenation).

In the example you provided, "1" + 2 is equivalent to "1" + "2", but you're making the interpreter do more work.

QED: "1" + 2 should, in fact, === "12", and your lack of ability to handle a language where you declare types by symbols rather than spending extra effort writing the type out as a full english word is your own shortcoming. Learn to declare and handle types in dynamic languages better, don't blame your own misgivings on the language.

Signed, a software engineer.

Well, C has implicit casts, and it's not that weird (although results in some interesting bugs in certain circumstances). Python is also funny from time to time, albeit due to different reasons (e.g. -5**2 is apparently -25 because of the order of operations)

Typing and function call syntax limitations are exactly why I hate JS.

They've declared it as WONTFIX, so unless you're suggesting that OP creates a fork of numpy, that's not going to work.

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.

here’s a good question answer on this topic

https://stackoverflow.com/questions/18922407/boolean-and-type-checking-in-python-vs-numpy

plus this is kinda the tools doing their jobs.

bool_ exists for whatever reason. its not a bool but functionally equivalent.

the static type checker mpy, correctly, states bool_ and bool aren’t compatible. in the same way other type different types aren’t compatible

Technically the Python bool is fine, but it's part of what makes numpy special. Under the hood numpy uses c type data structures, (can look into cython if you want to learn more).

It's part of where the speed comes from for numpy, these more optimized c structures, this means if you want to compare things (say an array of booleans to find if any are false) you either need to slow back down and mix back in Python's frameworks, or as numpy did, keep everything cython, make your own data type, and keep on trucking knowing everything is compatible.

There's probably more reasons, but that's the main one I see. If they depend on any specific logic (say treating it as an actual boolean and not letting you adding two True values together and getting an int like you do in base Python) then having their own also ensures that logic.

Someone else points out that Python's native bool is a subtype of int, so adding a bool to an int (or performing other mixed operations) is not an error, which might then go on to cause a hard-to-catch semantic/mathematical error.

I am assuming that trying to add a NumPy bool_ to an int causes a compilation error at best and a run-time warning, or traceable program crash at worst.