On Wed, 3 Apr 2002, Guido van Rossum wrote:
> 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:".
Yes yes. I understand this part just fine. It's not the *listening*
i'm concerned about -- 'if' takes care of that easily for me. It hears
[], None, 0 as false and hears 'spam', {1: 2}, 47.3 as true.
It's the *speaking*. When i want to say true or false, then there's
the dilemma.
I know, your answer is "you should always just say True or False",
and Mark McEahern said the same thing. But this cannot be so in
practice: *everything* already returns 0 or 1. (It may be possible to
get around this if we commit to changing the entire standard library
before releasing a version of Python with True and False, but alas,
this is not the only issue... read on.)
As long as True and False are somewhere represented as 0 and 1,
the values 0 and 1 will never lose legitimacy as booleans. This
business with str() and/or repr() producing "0" or "1" for backwards
compatibility prevents us from considering 0 and 1 relegated to a
truly non-boolean status.
Consider this:
>>> a = [0, False, 1, True]
>>> print a
[0, 0, 1, 1]
>>> for x in a: print x
0
0
1
1
Good heavens!
What about this:
>>> d = {}
>>> d[0] = 'zero'
>>> d[False] = 'false'
>>> len(d)
1 or 2?
Basically, the concept of having a permanently schizophrenic type
in the language scares me. The above shows, i believe, that a
reasonable implementation must print True as True and False as False,
and never mention 1 or 0. Moreover, as soon as you start sorting a
bag of objects, or keying dictionaries on objects, you are forced to
run into the distinction between 0 and False, and between 1 and True.
I'm not against the idea of booleans, of course -- but i do think
that halfway booleans are worse than what we have now. And getting
to real booleans [*] involves real pain; it's just a question of
whether that pain is worth it. Even if we get all the way there --
as in we manage to convert enough code and convince everyone to use
the new style -- i will never ever want "and" and "or" to return
booleans (i just hope that doesn't confuse anyone).
-- ?!ng
[*] By real booleans, i mean the following. (Booleans would have
to behave like this for me to consider them "good enough" to
be better than what we have now.)
>>> False, repr(False), str(False)
(False, 'False', 'False')
>>> True, repr(False), str(False)
(True, 'False', 'False')
>>> False + True
TypeError...
>>> False == None
0
>>> False == 0
0
>>> True == 1
0
>>> {0: 0, False: False, 1: 1, True: True}
{0: 0, False: False, 1: 1, True: True}
... and probably
>>> None < False < True < 0
True
(Hee hee -- i suppose the fact that "boolean" starts with a "b"
gets us this for free. But i wonder how many people are going
to be puzzled by True < 0?)
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