PEP 285: Adding a bool type

[Chris Liechti]

Guido van Rossum <guido at python.org> wrote in 
news:3CAB0015.6563C468 at python.org:

> Someone wrote:
> 
>> It's a cost/benefit thing.  Type/class unification may have cost more
>> in complexity than bools cost, but it has high benefits.  The bool
>> thing would a complicated change with limited benefit, so it's provoked
>> some sharp reactions.
> 
> That's an interesting response, because it highlights what I think is
> the main misunderstanding about the PEP.  You should think of it a
> very *small* change!
> 
> Some operations that conceptually return a truth value (like a==b)
> have to pick something to represent that result.  This is only needed
> when no other object among the operation's arguments is suitable to
> represent the result, for example in "not x".  While almost any value
> is usable to express a truth value, traditionally the Python core and
> standard library have consistently picked 0 to represent falsehood
> and 1 for truth.
> 
> A problem with this is that the intention isn't always clear.  Does a
> particular 1 represents a specific count or is it simply a
> representative of truth?  While ultimately this is a matter of
> documentation, having a notation helps clarify the matter (in cases
> where it is used).

i see that as a very good reason for having a bool type

> To solve the problem of clarifying intent, the PEP introduces two new
> values that the core will use in preference over 0 and 1, and standard
> names for them.  It makes them the only values of a new type, so that
> they can be recognized as the canonical representatives when
> necessary.  For backwards compatibility, these values act just like
> the integers 0 and 1 in non-Boolean contexts (except when printed or
> converted to a string).  For simplicity of implementation, and to
> guarantee backwards compatibility at the C level, the new type is
> implemented as a subtype of the built-in int type.

quote from the PEP
"""
    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 for example 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, one should use "if", as in "if x: print 'Yes'", not
    comparison to a truth value; "if x == True: print 'Yes'" is not
    only wrong, it is also strangely redundant.
"""

here i disagree.

6 == True and 7 == True does _not_ infer 6 == 7. when using an 'if' nobody 
thinks that way neither:
>>>if 6: print "True"
>>>if 7: print "True"
both print True but nobody would think they're equal.

i think the concerns above come from the background of _knowing_ that bool 
is a subclass of int. but thats an only implementation detail. when you 
teach that True and False are the prefered values for Something/Nothing in 
a boolean context that is no problem. that their value is 1 resp. 0 in a 
numerical context is the most useful choice regardles of any inheritance 
from int.

i would rather tolerate a bit more broken code if only '6 == True' -> True 
beacuse i think that feels better and is better to understand for newbees 
and newcommers from other laguages.
its more tolerable to have a redundant way than having to explain the 
reasons why 'True == 1' but not 'True == 6' but both 1 and 6 are True when 
used with 'bool(x)' or 'if x:'.

> No user code needs to be changed unless it is sensitive to the string
> representation of Python objects.  There is no prejudice against user
> code that continues to use 0 and 1 (or something else) to represent
> truth values.

but there should be a clear recomendation. when it especialy useful to have 
a bool type for RPC etc. anyone should get used to it because he might use 
his code later in an RPC environment.

> In order to give people coming from (or going to) other languages an
> easy time getting used to the new type, it is called bool, and its
> values are called False and True.  But like so many things in
> Python[*], its bool type acts slightly different than the Boolean type
> in other languages.  That's fine -- other languages don't all agree on
> the details of Boolean types anyway, varying from very strict (Pascal,
> Java) to very loose (C, Lisp).

i like the name 'bool' its a clear name where you can catch the intended 
use of the type and you learn/use someting that will come up again an again 
in CS. and short is good as it saves typing but is still very readable.

> This is long enough of a response.  To those people who complain that
> I don't take their long thoughts seriously, I can only respond that I
> thought long and hard about this PEP too, and am similarly disappointed
> that it faces so much opposition based upon what *might* happen.

don't see that too negative. some posters may fear that their voice is not 
heard and write big words. it's also a rare oportunity that an aspect of 
the language is discussed in the open newsgroup/list in that way, so 
everyone wants to have said someting. the discussions about the PEPs are 
not that immediate/close to the real Python as when you ask "should this be 
accepted".
i guess when you apply a "median" filter on all the answers and weight if a 
reason is more "fear from the unknown" or more fundamental you will get 
valuable information from the discussion.

i still think that offering a PEP for discussion is a valuable thing and i 
appreciate it. i hope we will see it in again in the future.
it makes many of us think of "our" Python instead of just "that Python" (it 
brings in some emotion, an hence the hot discussion).

chris

PS: 
you should also note that the PEP has been updated and that many of the 
open points crystallize to clear statements.

> --Guido van Rossum (home page: http://www.python.org/~guido/)
> 
> [*] Take variables for example.  You can write "x = 1" in Python just
> as in C or Perl, and superficially it does the same thing.  But the
> meaning is profoundly different!  1 is an object, and x is a name
> binding for that object.  This goes on in Python all the time: other
> examples are x+y, for loops, even function argument default values.
> Booleans have their own twists and always had ("if x", "x and y").
> Python is not unique here either -- many language have different
> semantics underneath familiar notations, and this can represent a real
> breakthrough (like Smalltalk, which redefined x+y as sending the
> message "+y" to the object x).
> 



-- 
Chris <cliechti at gmx.net>