[Python-Dev] PEP 285: Adding a bool type

[Stuart Bishop]

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/