> The addition of another type really does change the set of preferred
> truth values from {0, 1} to {0, False, 1, True}. The typical
> practicing Python programmer who wants to say "true" would have to
> decide -- for each instance -- whether to say "1" or "True".
No. If they want to use the *recommended* values they should always
use False or True. 0 and 1 are relegated to the domain of
non-representative values of the set of false and true objects, just
as None and "true" (the string literal).
> And the programmer cannot happily ignore the issue and stick to
> using 0 and 1, because if comparisons start to return True and
> False, dealing with a mix of four truth values is unavoidable. This
> PEP makes me uneasy because it causes me to see lots of extra casts
> in Python's future (not to mention confused beginners).
You misunderstand it. Strings, lists, numbers and so on are still
acceptable as truth values, and when you want to know whether x is
true or false, you still have to say "if x:" -- never "if x == True:".
In addition, for backward compatibility 0 == False and 1 == True, so
mixing them shouldn't be a problem if you know your values are
chosen from the set {0, False, 1, True}.
If you find yourself comparing an unknown value x to a known truth
value to determine whether x is true or false, stop right there:
you've *already* got a problem. If you don't have a problem because
it works in practice (meaning x is known to be 0 or 1) the backwards
compatibility of the PEP kicks in and saves your butt. This won't
be deprecated: the PEP promises that False==0 and True==1 will always
hold. (There's a question for reviewers about this, but consider it
decided -- bools will always mix freely with ints.)
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4