Oh boy, that didn't age well for Python language did it? It matches with C++ in growing complexity of syntax features. With a couple dozen ways to write the very same algorithm.
Every primitive type has a null value, and the "if" statement tests for such a value. Whether a value is true or false is a property of the value. Notice that "true" and "false" are adjectives, not nouns.
That is a simple, internally consistent model with one concept of trueness.
The introduction of the boolean type made this a lot messier: it makes "if" look like type coercion, and introduces two different ways to think of boolean-ness (as an adjective or as a noun) which you must hold in your head at the same time. For example, it became possible to compare things as equal to True or False, doubling the number of ways to express a condition: "if x" and "if x == True" are now very similar, but subtly different, ways to express the same thing. The fact that we have to talk about things as "truthy" or "falsy" as if these were different from "true" and "false" is a further illustration of the mess this has created.
If we had stuck with 0 and 1, we would have avoided all this confusion. It is imperfect but simple; what we ended up with is still imperfect and needlessly complicated.
I am not sure if that perspective aligns with yours.
In an explicitly, statically typed language, bools might be useful as a standard small enum.
In what Python used to be, they weren't, not really.
But for whatever reason, declared typing is now an add-on to the language, and the people who like the verbosity of declared typing also, perhaps schizophrenically, like the terseness afforded by having a standard small enum.
The addition of boolean `True` and `False` were a huge improvement to the language when they were finally added in 2.3.
I'm not sure why you're making things more complicated than they need to be. Test for truthiness. Conditional statements already evaluate boolean expressions, you're not adding anything explicit by writing `== True`.
Argument by verified hoarder?
> The addition of boolean `True` and `False` were a huge improvement to the language when they were finally added in 2.3.
Hard disagree.
Does it? "bank account has 0 dollars" and "no bank account" are different states. 0 cannot (should not) try to represent both. Same for empty string, empty list, empty set, they are data not nulls. Python has None for that.
Not if you just use the objects as their natural types. For example:
>>> "" == False
False
>>> "a" == True
False
No, they're not. See above.
I don't see how. Indeed, using 0 and 1, the int values, as if they were boolean false and true created more confusion. First, int has more values than just 0 and 1--and all of them are "truthy". Second, treating 0 and 1 as booleans is still treating boolean-ness as a noun--but also confusing that with treating it as an adjective for those int values.
PEP 285, which introduced the bool type, gives other rationales as well:
In other traditions, type systems or the borrow checker or even vaguer things like a commitment to a "tiny core" of just a few primitives constrain language designers in a way that (sometimes inflexibly) commits them to the consequences of earlier design decisions. Python has mostly been designed one step at a time, by fiat. It's not a surprise that the result is an inconsistent language, especially after the resignation of the BDFL, and especially after so many years of widespread popularity.
`which python` --version> "You have Tim to thank at least partially if you were a refugee from Java or Microsoft languages, which made excuses for their sprawling verbosity, complexity, and poor readability. Python, at the time, made none of those and had none of that (it now does). Tim was crucial in ensuring it stayed that way during his most active years. He will claim differently, but, by my observation, it is no accident that Python ballooned in complexity after his exit as day-to-day core developer."