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/)