Preach. We need more Python slander. It annoys me to no end when people trash JavaScript as if it was some exception in bad language design. Most languages have something bad that can be picked up and trashed on - some more than others.
Both aren't perfect languages, and both are far from "the best" but it is maddening that Python get often picked as a darling when its implementation, ecosystem and tooling are fundamentally at odds with correctness and productivity.
This is not idiomatic Python code. It's code designed to demonstrate Python performance optimizations, through use of relatively obscure Python functionality which exposes details of the internals in situations where you need that.
"its implementation, ecosystem and tooling are fundamentally at odds with correctness and productivity"
You'll need a lot more than just this notebook to argue for that position.
But, if you have any suspicion that JavaScript has been treated unfairly: it hasn't. It is literally being replaced by TypeScript as we speak. The fact you have to invite people to come up with more Python slander is itself a testimony, JavaScript has never needed an invitation. Having lot more issues than others is what being exception means, and JavaScript is one.
Python's file system support across platforms is notoriously problematic or even outright broken. Wasn't this enough reason to put it lower in the quality bar than JavaScript?
It would not be a positive change to sacrifice Python performance in order to make the output of id() more intuitive. I've spent many hundreds of hours coding Python and I don't believe I ever used that function or saw someone else use it.
[1]: https://docs.python.org/3/library/functions.html#id
[2]: see e.g. https://stackoverflow.com/questions/52096582
Do you think there should be different results for bool("no"), bool("false"), bool("heckno!"), bool("heckyes!")?
Edit: should have included internationalization: bool("nein!")
But it's entirely reasonable to think it would. I honestly don't understand why it wouldn't, because:
>>> int("35")
35
>>> float("3.5")
3.5
>>> bool("False")
True
And of course it doesn't need to work for "no" or "heckno!", that's silly. But it sure seems like it ought to work on whatever the official string representation is. And not produce:
>>> bool(str(False))
True
prefer bool() threw an exception on receiving a string, rather than act the way it does now.
a = 1 # or [], (), "yo", "false", 3.2, MyFooClass(), (1,), False
if a:
fire_ze_missles()
else:
declare_peace()
It can short-circuit the brain upon reading a word that you know means false, but the Python rules are consistent. "Empty" is False, everything else is True.
> I'd honestly much prefer bool() threw an exception on receiving a string, rather than act the way it does now.
They serve fundamentally different purposes. bool() is a truthiness check and not a type cast like int() and float(). It seems like a lot of people take issue with the name, because it was called something like istruthy() the discussion about it wouldn't be happening.
Right, the bug is in the inconsistent naming.
It's roughly as bad as having arithmetic operators named +, -, *, / that perform arithmetic as usually understood, except that + actually performs XOR and is documented to do so.
The comment I responded to didn't seem to realize that because they asked why it behaves the way it does, so I explained.
`bool` would have no value if it threw an error in this case because if strings can't be passed to it, then no other type would sensibly work either. It would basically just become `bool(False) -> False` and `bool(True) -> True`.
It's pretty standard to convert integers to bools, where 0 becomes False and everything else becomes True. That is absolutely sensible and useful current behavior.
Not consistent at all.
There's nothing consistent about bool(str(False)) == True.
It's standard in computing for zero integers to represent False. Heck, bool is a subclass of int. Extending that to the length of strings is where things start to go off the rails in terms of consistency... and why you would ever even want that is beyond me.
Which becomes a different issue - what do you think str(True) and str(False) should produce. Integer representations? That then makes other things unintuitive with changing the form of a boolean.
print(0, 1, False, True)
# today: 0 1 False True
# as ints: 0 1 0 1
# new str: 0 1 "True" ""str(False) == 'False' is entirely logical.
So therefore bool('False') == False would be consistent.
And bool('foo') would produce an exception the exact same way int('foo') and float('foo') already do.
Who on earth thought it was a good idea that 'foo' could or should be interpreted as a boolean...?? The entire concept of 'truthiness' outside of ints is unhelpful. It's just asking for bugs. That the length of a string, rather than its content, should determine a boolean value is one of the more bizarre things I've come across in programming languages. Use len() if you want that. It's only 5 extra characters.
There's no type casting in Python. int(), float() and bool() just create objects of their respective types, passing the arguments to the initializer. They are not fundamentally different from, say, PostgresqlDriver() in this regard.
Different classes will provide different ways to construct objects depending on what is most useful. For int and float, the most useful thing to do when receiving a string is to parse it; for bool, the most useful thing to do is to check its truthiness; for PostgresqlDriver, the most useful thing to do is to interpret it as a database URL and connect to it.
If you search "type casting in Python" you will find lots of articles explaining how to use int(), str(), etc. to cast. This is a common and well-documented concept, even if it's different under the hood from e.g. C.
The idea that you'd name a function bool() and have it act differently is a deeply confusing design decision that it's understandable people would get misled by and frustrated with. This is a function named after a fundamental type. It's not a random user-defined constructor.
if "False":
# What do you expect? True or False?
print("True")
else:
print("False")
if bool("False"):
print("True")
else:
print("False") # This would be different if we landed here.
Honestly it's not that hard to write something that looks like this:
def str_to_bool(val: str) -> bool:
return val.lower() in ["yes", "true", "1"]https://docs.python.org/3/library/functions.html#bool
A good tutorial will reflect this fact and use appropriate language.
Both the idea that you can "cast", and the idea that bool is a function, are misunderstandings rooted in the idea that Python should be like C in all ways.
int() and float() behave like type casting, bool() does not. It's a truthiness check that would be more aptly named istruthy(). In python non-empty strings are truthy, so providing any string except for "" to bool() will return True, including "False".
(char*)21 != "21"
What you're reaching for is type conversion. Some languages have "implicit conversion" when casting, but the word itself doesn't require it.
A cast of insert a conversion that wouldn't take place:
1/2 vs 1/(double)2
bar *b = 0;
foo *f = (foo *) b;
Because I'm tired, and this is a very basic topic, I'm afraid I'm just going to rip from Wikipedia:
> In most ALGOL-like languages, such as Pascal, Modula-2, Ada and Delphi, conversion and casting are distinctly different concepts. In these languages, conversion refers to either implicitly or explicitly changing a value from one data type storage format to another, e.g. a 16-bit integer to a 32-bit integer. The storage needs may change as a result of the conversion, including a possible loss of precision or truncation. The word cast, on the other hand, refers to explicitly changing the interpretation of the bit pattern representing a value from one type to another. For example, 32 contiguous bits may be treated as an array of 32 Booleans, a 4-byte string, an unsigned 32-bit integer or an IEEE single precision floating point value. Because the stored bits are never changed, the programmer must know low level details such as representation format, byte order, and alignment needs, to meaningfully cast.
> In the C family of languages and ALGOL 68, the word cast typically refers to an explicit type conversion (as opposed to an implicit conversion), causing some ambiguity about whether this is a re-interpretation of a bit-pattern or a real data representation conversion. More important is the multitude of ways and rules that apply to what data type (or class) is located by a pointer and how a pointer may be adjusted by the compiler in cases like object (class) inheritance.
Implicit conversion can be seen as the compiler deciding among several possible conversions (or possibly just one) and inserting the coercion/casting operator into the intermediate code to make it happen.
(Of course, this can be a run-time decision based on dynamic types also, but the reasoning is the same. E.g. the run-time sees that a plus operation is adding an integer and float, and can either signal an error (requiring the program to be repaired by inserting a conversion operation into the expression), or just do that conversion, like the integer operand to float.
Otherwise types are just sugar. Indicies are just sugar. Lists are just sugar.
That said, I think you're correct about the casting versus conversion distinction. Languages frequently overload established terminology with slightly modified variants and it's incredibly confusing.
in raku, i checked
say False.so; #False say "False".Bool
say "False".so
Leaving out the quotes means you're testing something else entirely.
Note that the Python example is converting (via `bool`) a string with the text "false" (which would make more sense as "False" which is the actual name of `False` in Python) into a boolean value. It's consistent with how Python behaves, in that the empty string (like in Raku from what I can tell) is false-y and non-empty strings are truth-y. It would be weird to have this use the else branch:
if bool("False"):
...
else:
...
if "False":
...
else:
...Generally python is much better than some other dynamic languages in avoiding stringly typed confusion, but the convenience of the int from string constructor set expectations that the rest of the language can't sanely meet.
String to type construction should have been relegated to a dedicated syntax in all cases.