PEP 285: Adding a bool type

[Steve Holden]

[posted & mailed]

"Guido van Rossum" <guido at python.org> wrote in message
news:3CAE52CA.60F56E3D at python.org...
[ ... ]
> By then, so many words had gone back
> & forth that I didn't feel like going back and responding to her piece in
> detail -- others had done that and the discussion had blown up to such a
> volume that I didn't think I could convince any of the PEP's detractors
> anyway.  I apologize to Laura that my judgement came across as rude.
>
Dismissive rather than outright rude, but given the storm of opinion raised
by this PEP, some of it less than well-informed, I can certainly understand
how this happened.

[ ... ]
> > >
> > However it happened, it left me feeling a little embarrassed that I had
> > originally defended Guido's inegrity and suggested that despite his
> > authorship the PEP's acceptance was not a foregone conclusion. I hope I
> > wasn't wrong, but that's not how it looks right now. Oh well.
>
> I'm sorry I embarrassed you.  Despite how it looks, acceptance of the PEP
> was *not* a foregone conclusion.  I have looked carefully for a killer
> reason against its acceptance, and did not find it.  I found a lot of
> disagreement on what people consider a "real" Boolean type.  I did find
> wide agreement on something that I had myself taken for granted, but which
> some proponents of "real" Booleans were challenging: the usefulness of
> Python's ability to test almost *any* object for its truth value, what
> Laura calls something/nothing.
>
No need for any apologies to me. I wouldn't dream of trying to have *my*
opinions constrain *your* behavior, and wouldn't want the responsibility if
they did ;-).

Certainly appearances can be deceptive, and I think anyone who's tracked
Python's development over a number of years knows you *do* take input
seriously, even when it exasperates the ... heck out of you.

> Finally, some folks believe that the new bool should not behave like an
> int.  I've thought about this too.  *Maybe*, if I had added a bool back
> in 1990, I would have agreed and introduced a "pure" bool type.  Right
now,
> if I added such a type, it would not be usable as the return value of
> comparisons and other operations that return a binary result, because of
> backwards compatibility.  And backwards compatibility is a key requirement
> for all language changes (see the division discussion).  Backwards
> compatibility would forever prevent returning a pure bool from existing
> built-in operations.  The only possible transition path has to use an
> "impure" bool like the PEP proposes.  Then the only open item is whether
> this should be considered an impurity that should be deprecated, or a
> permanent wart in the language.  I believe that it's a useful enough wart
> that it can be allowed to stay, and I don't believe that the language
> would be easier to learn or use with pure bools, so I think there's no
> point in deprecating it.  But if years from now our experience points
> out that there is in fact a problem with impure bools, I'm willing to
> reconsider.  However, since I see no way to get there without going
> through the impure bool, I see no reason to wait in implementing the PEP
> *now*, and that's what I have done.
>
> Summary: the impure bool makes it *possible* to transition to a pure bool
> *if* we find that a pure bool is needed; introducing a pure bool from day
> one would be impossible without breaking reams of existing code.
>

Understood. Code breakage is definitely to be avoided. I don't think Python
has too many warts overall (and won't repeat my prejudices on that topic
here).

regards
 Steve