"Guido van Rossum" email@example.com writ:
Dear reviewers: I'm particularly interested in hearing your opinion about the following three issues: 1) Should this PEP be accepted at all.
Depends on the resolution of #2 and #3 ;-)
2) Should str(True) return "True" or "1": "1" might reduce backwards compatibility problems, but looks strange to me. (repr(True) would always return "True".)
str(True) must return 'True' or there isn't much point in bothering with this, IMO.
3) Should the constants be called 'True' and 'False' (corresponding to None) or 'true' and 'false' (as in C++, Java and C99).
As a language interoperability guy, I prefer to keep as much precise correspondence as possible with C++ (and Java), so I vote for 'true'/'false'.
Most other details of the proposal are pretty much forced by the backwards compatibility requirement; e.g. True == 1 and True+1 == 2 must hold, else reams of existing code would break.
Guess what other language made that same choice for the same reasons?
Minor additional issues: 4) Should we strive to eliminate non-Boolean operations on bools in the future, through suitable warnings, so that e.g. True+1 would eventually (e.g. in Python 3000 be illegal). Personally, I think we shouldn't; 28+isleap(y) seems totally reasonable to me.
Changing my position somewhat from earlier, I'll vote in my project's self-interest: I agree with your inclination to allow bool to be "promoted" to an int in these conditions.
5) Should operator.truth(x) return an int or a bool. Tim Peters believes it should return an int because it's been documented as such. I think it should return a bool; most other standard predicates (e.g. issubtype()) have also been documented as returning 0 or 1, and it's obvious that we want to change those to return a bool.
I agree again!
6) Should we eventually remove the inheritance relationship between Int and Bool?
I hope so. Bool is-a Int doesn't seem like the right relationship to me, unless perhaps we make Int is-a Long... naah, not even then.