PEP 285: Adding a bool type: yes, but not as int subtype

[Paul Sidorsky]

Ype Kingma wrote:

> A bool is a bool and an int is an int.
> The only relation between them is that they have to be implemented using
> bits of a computer.
> Python is sufficiently high level not to care about the bits.

Wow, wait long enough and somebody will say exactly what you're
thinking.  I pretty much agree 100% with everything Ype wrote.

I am totally in favour of a boolean type.  Writing "value = 1" instead
of "value = True" has seemed wrong ever since I started with Python.  I
feel it important to add a definitive "yea" on this since there has been
quite a bit of resistance to this PEP so far.  However, while I think
it'd be great to have a bool type, I think it would be even better to
see it done "right" from the start.

>From what I have read on python-dev it looks as if the desire to mix
ints and bools stems mainly from wanting to preserve backward
compatibility.  However, it seems to me that allowing ints and bools to
be interchanged somewhat is going to create a lot of situations where
the two of them get mixed in the same module.  Old code will use ints,
while newer changes and additions will use True/False as programmers get
used to using them in new projects.  Maintaining these kind of modules
is going to be hell until somebody finally decides to correct everything
to the new style.  If this is going to be done anyhow, why not at least
force people it to be done right the first time?  People may gripe at
first at having to upgrade code, but in the end they'll be better off
than if they hadn't.

Hmmm, this seem like a good time to share my own horror story about what
can happen when you mix ints and bools.  This was in C (not C99 though)
so there was no bool type - just like Python is now.

I had a program that was storing a bunch of values, and in one part I
needed to know if just one particular value was there or not, so of
course I had assigned that value 0 and exploited the fact that I could
use "!value" to test for it quickly.  I needed this result a few times
so I assigned it to a variable.

Some time later I was adding features and found that in one case I
needed to know exactly what the value was, so I modified that part of
the program to use the same variable to store the actual value instead
of a truth value.  This meant that what was 0 (false) would now be a
positive integer, and vice-versa.  This must have slipped my mind
because I got the assignment the wrong way around.

This should have broken the program immediately, except that when I was
converting the the rest of this part of the program I had missed a
negation of the old value.  The result was essentially that of applying
"value = !(!value)".  The program still worked WRT the old truth checks,
but was completely unable to determine the actual value where I wanted
it to because the value could only be 0 or 1.  Needless to say, it took
a very long time to track this problem down.

This would never have happened if bools and ints were separate types. 
The extra negation would have meant I was trying to assign a bool to an
int and caused an error immediately.  Furthermore, I almost certainly
would never have _tried_ such a twisted approach to begin with.  I did
it the way I did because in C I _could_ do it that way.

Mixing ints and bools doesn't offer enough protection in my mind.  A
boolean type that can be partially interchanged with an int might have
prevented my nightmare above from happening, but not necessarily.  As I
said, though, a separate boolean type would have prevented this kind of
error from even compiling.  Having that kind of protection built into
the language is very appealing, at least to me.

I admit that in this case above the problem was ultimately the result of
my own stupidity.  However, if programmers weren't stupid the odd time
we wouldn't even need languages like Python because we'd all be able to
program in perfect C.  Heck, we might not even need C because we could
program in perfect assembly.  Given that we're not pefect, the job of a
high-level language should be to provide more protection for programmers
not from lower-level languages, but from themselves.

-- 
======================================================================
Paul Sidorsky                                          Calgary, Canada
paulsid at shaw.ca                        http://members.shaw.ca/paulsid/