[Python-Dev] PEP 285: Adding a bool type

[Guido van Rossum]

> It feels like there are too many combinations available in the
> PEP. (Or maybe too many questions and options which could result in
> weird combinations.) I'd like to see a new version with Guido's
> latest thoughts.

My thoughts haven't changed at all. :-)

The first round of discussion (on python-dev) brought up some
contentious issues where people disagreed strongly with particular
details proposed in the PEP, and I put those contentious issues at the
top of the review list.  If you go to the latest version of the PEP on
the web (http://www.python.org/peps/pep-0285.html) you'll see that
I've added some other issues that were brought up in the more recent
discussion.

> For example, are we closer to a resolution on the
> str() and repr() issues?  The only behavior I like is that exhibited
> by the sample code:
> 
> >>> str(True)
> 'True'
> >>> repr(True)
> 'True'

So far I believe only Marc-Andre has expressed himself against this,
so I'll make it so.

> How about the case of the constants: true, false vs. True, False? I
> like the latter, which match None. They would also stand out in the
> new docstrings mentioned by Fred.

Ditto.

> How about operator.truth()? Has Tim changed his mind at all? Has Guido?

I don't know about Tim.  I've made an executive decision that
operator.truth() will return a bool (making it an alternate spelling
for bool()).

> If this PEP were implemented and "all built-in operations that
> conceptually return a Boolean" were updated, what verifiable
> examples of code breakage would we have?

I've changed the list of operations explicitly mentioned in the PEP
(comparisons, some builtins, some string and file methods, a few other
things).  It breaks about 12 tests in the test suite.  I haven't
looked at all of these in detail, but I believe they are all shallow,
of the following form: a test does "print x == y" and then the output
is matched to "expected" output.  The expected output strings must be
changed from 0/1 to False/True.

> The issue of dictionary keys has been raised, and is a bit
> perplexing, but not overly so, IMO. However, I'd like confirmation
> that this is indeed the intended behavior:
> 
> >>> d = {}
> >>> d[0] = 'First'
> >>> d
> {0: 'First'}
> >>> d[False] = 'Second'
> >>> d
> {0: 'Second'}
> >>> d[0.0] = 'Third'
> >>> d
> {0: 'Third'}
> >>> d[()] = 'Fourth'
> >>> d
> {0: 'Third', (): 'Fourth'}
> >>> d[None] = 'Fifth'
> >>> d
> {0: 'Third', (): 'Fourth', None: 'Fifth'}

Yes.

> Or are there any situations like this where you would want True and
> False to be a bit more like None and a bit less like ints? Meaning
> True and False could be dictionary keys separate from 0 and 1.

No.  That would break backwards compatibility.  False==0, and True==1;
everything else follows from that.  (But False is not 0, and True is
not 1!)

> Other than that, are there any concrete issues that have been raised
> that need to be addressed by the PEP? I understand the uneasy
> feeling felt by many as I felt it myself. However, I've read all the
> newsgroup postings and reread the PEP and I don't feel very queasy
> any more. I think this PEP is a step in the right direction. I would
> hope that clarifying some of the genuine issues might help to bring
> about consensus and reduce some of the rhetoric.

There's an educational issue that I'm just getting my head around.  It
appears that for various psychological and linguistic reasons, newbies
naturally write

    if b == True: ...

when they first encounter a bool variable and have to test whether
it's true.  I believe that this is most of Laura's issue.  The only
reasonable solution for this is that the Zen master slaps them over
the head with a stick, and they learn to write

    if b: ...

I'll update the PEP.

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