PEP 285: Adding a bool type

[Ken Seehof]

> Guido:
> > Laura, you've said this over and over, and I don't buy it.
> > 
> > Two arguments from XP apply here:
> > 
> > - YAGNI (You Ain't Gonna Need It), or also "do the simplest thing that
> >   can possibly work".  If all you need today is a bool, use a bool.
> 
> Aha, now I understand a large part of why we disagree.  A bool is not
> simpler than an int.

Yes it is.  For example, a boolean can be fully interpreted and
processed by a single if statement.

> 'Something that can change state' is simpler than
> 'something that can change state and must only have one of two values'.

Is "Is it?" simpler than "What is it?" or isn't it?

> Do you go around making functions that return bool all the time, only
> then to change them to return int every time you have the idea that 
> there actually are 3 states here you want to model?  Then you will
> be littered with one obsolete 2-valued function every time this happens.
> They pile up, and since your wretched customers have all started using
> the 2-value functions, you are stuck having to maintain these things,
> even though you now hate them, and want everybody to use the 3-value
> versions.

Hmm.  My code isn't littered with obsolete "2-valued functions", and I've
been writing boolean functions since the first Borland C++ compiler was
released.  Actually I don't recall -ever- changing a boolean function to
return anything else.  I've simply never had the need.  You're still
missing the point: the concept of "2-value" functions is completely
separate from the concept of "boolean" functions.  Please separate these
two utterly distinct concepts in your mind.  A boolean function answers a
Yes/No question.  If you still don't understand this, I will be forced to
concede your earlier point, that the concept of "boolean" is difficult to
teach :-)

All of your examples fit in one of two categories:

1. Things that very clearly should not have been boolean in the first
place.  This includes anything that is not a Yes/No concept.

2. Things that should remain boolean, and would break everything if
changed to return more values.  These include anything that the user
expects a Yes/No from (based on documentation and naming).

You really shouldn't encourage your students to change interrogatory
functions to return 3 or more values.  It's a really bad idea.  Actually
go ahead, I don't mind.  When I'm 60, I might need a job fixing their
bugs :-)  The problem is that existing code expects a boolean value
(even if expressed as 0,1) and will break.

Note that if I wrote a function to classify your examples into the two
categories listed above, I would not use a boolean function.  Get it?

- Ken Seehof