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