PEP 285: Adding a bool type
Michael James Barber
mjbarber at ascc.artsci.wustl.edu
Mon Apr 1 08:17:20 EST 2002
True generally acts like 1 and False acts like 0.
So the following all are true (oh, this is going to be hard to talk
about!):
True == 1
False == 0
True != 2
We can use True and False arithmetically. I do realize that 'and' and
'or' are the more usual spellings, but let's see how things look.
So:
True + False == True # seems reasonable
True * False == False # also nice
True - True == False # OK
True + True != True # conceptually strange
Similarly, we can test of what class True and False are instances.
So, we have true statements:
isinstance(True, bool) # or whatever spelling is preferred for bool
isinstance(False, bool)
not isinstance(True + True, bool)
not isinstance(True - True, bool)
not isinstance(True + False, bool)
not isinstance(True - False, bool)
not isinstance(True * True, bool)
not isinstance(True * False, bool)
I'm opposed. Conceptually, it is identical to working with 1 and 0,
except that sometimes we'll see an alternate spelling and may have to jump
through some hoops to understand what's going on. I don't really see what
is gained by this, and there is increased conceptual overhead with reduced
clarity, IMO.
A version of truth types that handled arithmetic operators more smoothly
would better suit my tastes. I think this version pays too big of a cost
in clarity to maintain backwards compatibility.
--
Michael J. Barber
More information about the Python-list
mailing list