PEP 285: Adding a bool type

[Chris Barker]

Well, I've spent a great deal of time reading this thread, so I might as
well spend a little time putting in my $.02.

It seems to me that we have a fundamental problem here: a boolean type
is a great idea, and would be an excelent part of the Python language,
but it has not, as of yet, existed. In order to introduce one that
doesn't break a lot of existing code, it needs to be highly compatable
with the old system, which I think is a fundementally bad one. Frankly,
using 1 and 0 to mean true and false is bad enough, but every type (most
types?) also have values that can represent false ([], "", etc.). Having
the new boolean type mimic integers is probably the most pragmatic
solution, but fundamentally., using 0 and 1, rather than "" and "true"
is just a matter of convention. It is the most popular convention, by
far, but not defined in the current language. This makes it even harder
to come up with a backwards compatable solution.

I believe it was Alex Martelli who wrote the most convicing argument
that a boolean type that behaves almost exactly like the integers 0 and
1 is a bad idea. However, I am convinced that having a real boolean type
is such a good idea that it is worth a little pain in the transition.

By the way, here is an example of why the current sytem is bad:

string.find() returns the index of the found string, and 0 being a
perfectly valid index, it can NOT be used to return an indication that
the substring was not found, so -1 is returned instead. None could not
be returned to mean not found, because both 0 and None would resolve as false.
I'd love to see False be returned, and then you could do:

if string.find(...):
	do something.

There have been numerous threads from newbies (and not so newbies) who
tried to use this construct, and had it fail on them. Making the concept
of True and False separate from the concept of a value is a VERY good
idea. The number zero is a perfectly valid integer, having it stand in
for the concept of False is a bad idea. 

Of course, it is a major incompatabilty to have 0 not evaluate as false,
but I'd love to see the language head that way...Py3k maybe?

Here are my answers and comments to the original questions:

>     1) Should this PEP be accepted at all.
YES, YES, YES, ... but only if the intent is to make a purer boolean
type in the future.
 
>     2) Should str(True) return "True" or "1": "1" might reduce
>        backwards compatibility problems, but looks strange to me.
>        (repr(True) would always return "True".)

True.  str() is supposed to return an nice, human readable form of the
object. True is the only option for this. Anyone parsing the result of
str() should have been using repr(), and that will break anyway because
of the goal for eval(repr(x)) == x

>     3) Should the constants be called 'True' and 'False'
>        (corresponding to None) or 'true' and 'false' (as in C++, Java
>        and C99).

True and False, it fits better with Python and the rest of the languages
be damded
 
>     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.

which is too bad...

>     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.

I absolutely think we should!!! In fact, if we're not going to head
toward a more pure Boolean, then we shouldn't put one in at all. Others
have called this a slippery slope, and I agree, but it is one we want to
be at the bottom of, so we should get there slow, but not try not to get
there. 28 + True is just rediculous, it's only about saving a little
typing, a looks like a hack to me. What the heck is wrong with:

if isleap(y) :
	days == 29
else:
	days == 28

or, if you want to be more compact:

days = 28
if isleap(y): days+=1

for a language that doesn't have a "case" statement, this kind of
trickery just doesn't fit. By the way, using a bool as an index is even
worse: 

x = list[a == b]

is that clear??? I can't even use a float as an index:

x = list[math.floor(y)]

Why should I be able to use a bool.

>     5) Should operator.truth(x) return an int or a bool.

A bool. It could even be defined as

def truth(x): return bool(x)

yes, it's completely redundant with bool(), but it could be depricated
as well.

int(bool(x)) 
							
makes it quite clear what you want.

> Rationale
> 
>     Most languages eventually grow a Boolean type; even C99 (the new
>     and improved C standard, not yet widely adopted) has one.

People have dismissed this as irreleant, but I only somewhat agree. If
most langages do something, it doesn't mean Python should, but it does
mean that it probably has some good reasons to be considered.

>     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
>     those.

I've never done that, but I have always wanted a boolean type, I'd only
use it if it was a standard part of the language. As I made clear above,
I want it to be a lot different that just an integer that happens to be
valued 0 or 1.

>     I don't see this as a problem, and I don't want evolve the
>     language in this direction either; I don't believe that a stricter
>     interpretation of "Booleanness" makes the language any clearer.

Here's where I disagree. A stricter interpretation of "Booleanness"
would make the language clearer, and a type that sometimes act like an
integer, but isn't really, makes the language less clear. I think it's a
fine compromise during a transistion, but as it stands it just make
things more confusing, so if there is no intention of cleaning it up in
the future, don't make the mess now.


-Chris

-- 
Christopher Barker, Ph.D.
Oceanographer
                                    		
NOAA/OR&R/HAZMAT         (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov