PEP 285: Adding a bool type

[Guido van Rossum]

[Laura]
> I think there is a time and a place for bools --  Describing things
> that have two states that can never, ever, have 3 or more states.  
> These things are vanishingly close to non-existent, unless you are
> a mathematician in which case you may be playing with these sorts
> of things all the time.  What I am trying to do is save people
> like Mark McEahern from his isValid function, which returns whether
> a username is valid or not.  On the day his boss demands a third
> value - valid-but-I-won't-let-you-in-anyway-you-didn't-pay-your-bill,
> he will thank me.

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.

- "Refactor mercilessly".  If you find later that an int makes more
  sense than a bool for a particular function or variable, change it!
  It's not the end of the world.

In addition, it seems the same situation applies with all sorts of
other data types.  Why use an int when one day you might need a float?
Why use a float when you might need a complex number?  Why use a tuple
when you might need a list?  Why use a list when you might change your
mind and need a dict?

> That is what I mean by teaching people not to use bools -- teaching
> when not to use them. This is very hard to teach.  I know it because
> I have been doing it for years and years.   I even know _why_ it is
> hard to teach, but that doesn't make it any easier.

Have you been teaching Python all those years?  I'd like to get to the
bottom of this, because it's so against my own intuition.  I haven't
been teaching, but I've sure helped a lot of people who were
struggling with programming problems -- both in C and in Python.

--Guido van Rossum (home page: http://www.python.org/~guido/)