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.
Protip: Before making any claims about the behavior of a language with a REPL, test them at the REPL.
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: