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.
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?
I/O Issues are problems that come with the territory for scripting languages like python. Its why I prefer to use bash for scripting instead, because in bash, all I/O are strings. And if there are ever any conflicts, well that’s what awk/sed/Perl are for.
What exactly is your use case for treating np.bool_ and bool as interchangeable? If np.bool_ isn’t a subclass of bool 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 a bool but gets an np.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 ?
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)
"1" + 2 === "12" is not unique to JS (sans the requirement for the third equals sign), it’s a common feature of multiple strongly typed languages. imho it’s fine.
“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.
Good meme, bad reasoning. Things like that are why JavaScript is hated. While it looks the same, It should never, and in ANY case be IMPLICITLY turned into another type.
What reasoning? I’m not trying to make any logical deductions here, I’m just expressing annoyance at a inevitable, but nevertheless cumbersome outcome of the interaction between numpy and mypy. I like python and I think mypy is a great tool, I wouldn’t be using it otherwise.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
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?
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 aboolbut functionally equivalent.the static type checker mpy, correctly, states
bool_andboolaren’t compatible. in the same way other type different types aren’t compatibleI/O Issues are problems that come with the territory for scripting languages like python. Its why I prefer to use bash for scripting instead, because in bash, all I/O are strings. And if there are ever any conflicts, well that’s what awk/sed/Perl are for.
What years of dynamic typing brainrot does to mf
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.
This explanation is pretty clear cut
mpy and numpy are opensource. You could always implement the fix you need yourself ?
They’ve declared it as WONTFIX, so unless you’re suggesting that OP creates a fork of numpy, that’s not going to work.
Well, yes exactly
That’s incredibly inconvenient.
Thats what adding strong typing does for you
these dumb workarounds prevent you from shooting yourself on the foot and not allowing JS-level shit like
"1" + 2 === "12"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**2is apparently -25 because of the order of operations)"1" + 2 === "12"is not unique to JS (sans the requirement for the third equals sign), it’s a common feature of multiple strongly typed languages. imho it’s fine.EDIT: I did some testing:
What it works in:
What produces a number, instead of a string:
What it doesn’t work in:
And MATLAB appears to produce 51, wtf idk
The numeric value of the ‘1’ character (the ASCII code / Unicode code point representing the digit) is 49. Add 2 to it and you get 51.
C (and several related languages) will do the same if you evaluate
'1' + 2.Oh that makes sense. I didn’t consider it might be treated as a char
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 writingstring myString = "1"in a statically typed language. You declare it in the symbols used to write it instead of having to manually write outstringevery 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 followingidentify the operands from left to right, including their types.
note that the very first operand in the list is a
stringtype as you explicitly declared it as such by putting it in quotes.cast the following operands to
stringif 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" + 2is equivalent to"1" + "2", but you’re making the interpreter do more work.QED:
"1" + 2should, 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.
TypeError is also a correct response, though, and I think many folks would say makes more sense. Is an unnecessary footgun
Good meme, bad reasoning. Things like that are why JavaScript is hated. While it looks the same, It should never, and in ANY case be IMPLICITLY turned into another type.
What reasoning? I’m not trying to make any logical deductions here, I’m just expressing annoyance at a inevitable, but nevertheless cumbersome outcome of the interaction between numpy and mypy. I like python and I think mypy is a great tool, I wouldn’t be using it otherwise.
Why use bool when you can use int?
just never #define true 0