On Saturday, March 30, 2002, at 04:39 PM, Guido van Rossum wrote:
Abstract
This PEP proposes the introduction of a new built-in type, bool, with two constants, False and True. The bool type would be a straightforward subtype (in C) of the int type, and the values False and True would behave like 0 and 1 in most respects (for example, False==0 and True==1 would be true) except repr() and str(). All built-in operations that conceptually return a Boolean result will be changed to return False or True instead of 0 or 1; for example, comparisons, the "not" operator, and predicates like isinstance().
On a side note, writing 'i or False and True' performs much better than bool(i) in the test implementation, and flow control statements involving ints are perform much better than flow control using bool. Will there be a performance degredation in the final version, or can this be avoided?
1) Should this PEP be accepted at all.
-0 The only advantage I see is that there is a standard type for jython and other tools that need a boolean type can use. This is also a disadvantage, as all we really have is an object that may magically turn into an int if you are not careful. If you actually need a bool, you will always need to cast it 'just in case'. The only reason there is to modify existing code to return a bool rather than an int is so that repr(1 > 0) == 'True'. Consider: a = getflag() if a is None: print 'Unset' elif a is True: print 'True' elif a is False: print 'False' The above code reads well, but is incorrect unless we are sure what we are going to find in 'a'. The correct way to write the code is exactly like we do currently - adding a bool type adds nothing to Python code. I think of truth in Python is a state.
Most other details of the proposal are pretty much forced by the backwards compatibility requirement; e.g. True == 1 and True+1 == 2 must hold, else reams of existing code would break.
Minor additional issues:
4) Should we strive to eliminate non-Boolean operations on bools in the future, through suitable warnings, so that e.g. True+1 would eventually (e.g. in Python 3000 be illegal). Personally, I think we shouldn't; 28+isleap(y) seems totally reasonable to me.
non-Boolean operations should be eliminated eventually, so True + 1 raises a value error and True + True == True. 28+isleap(y) is an abuse of a side effect. If you want to add the return value to an integer, then you should return an integer and name your function correctly. 28+leapdays(y) is correct in my book, or 28+int(isleap(y)) if you don't live in Sweden.
Most languages eventually grow a Boolean type; even C99 (the new and improved C standard, not yet widely adopted) has one.
Many programmers apparently feel the need for a Boolean type; most Python documentation contains a bit of an apology for the absence of a Boolean type. I've seen lots of modules that defined constants "False=0" and "True=1" (or similar) at the top and used
Many programmers also feel the need for strong static typing in the language too - and I feel that this is intimately related to this PEP. The advantage of a bool type in a language like Java is that if I try to add an integer to a bool, I get a compile time error. Also note that, at least in C and Java, 'and' and 'or' return a boolean value - we can perform a series of boolean operations and know we will end up with 0 or 1 in C, and a boolean in Java. In Python we could end up with anything, and this behavior is relied on as one of the strengths of the language. There is current a concept of true and false as a state, not a value (or as another said, Something or Nothing).
It has been suggested that, in order to satisfy user expectations, for every x that is considered true in a Boolean context, the expression x == True should be true, and likewise if x is considered false, x == False should be true. This is of course impossible; it would mean that e.g. 6 == True and 7 == True, from which one could infer 6 == 7. Similarly, [] == False == None would be true, and one could infer [] == None, which is not the case. I'm not sure where this suggestion came from; it was made several times during the first review period. For truth testing of a value, one should use "if", e.g. "if x: print 'Yes'", not comparison to a truth value; "if x == True: print 'Yes'" is not only wrong, it is also strangely redundant.
This reads like an illustration of false logic. 'My dog is brown. My cat is brown. Therefore by dog is my cat'. -- Stuart Bishop <zen@shangri-la.dropbear.id.au> http://shangri-la.dropbear.id.au/