- Should this PEP be accepted at all.
I can do without it, but wouldn't mind it, as long as bools don't get too strict (like point 4, below). IMHO, Python's traditional concept of truth is much better than a Pascal-like concept of truth.
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".)
If str and repr were to behave differently from each other, I'd expect repr(True) to return "1" and str(True) to return "True". Interchanging that seems strange.
OTOH, I'm worried about backwards compatibility.
3) Should the constants be called 'True' and 'False' (corresponding to None) or 'true' and 'false' (as in C++, Java and C99).
'True' and 'False', please. It makes shadowing of the built-in values by user defined variables much less likely.
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.
IMHO, `28+isleap(y)` is certainly better than `28+int(isleap(y))`.
Used judiciously, booleans in arithmetic expressions can improve readability over conditional statements.
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'd expect operator.truth to be an alias for 'bool'.
If booleans couldn't be used in integer contexts any more, I'd prefer operator.truth to return an int <wink>.
Because of backwards compatibility, the bool type lacks many properties that some would like to see. For example, arithmetic operations with one or two bool arguments is allowed, treating False as 0 and True as 1. Also, a bool may be used as a sequence index.
Counting the number of true values in a collection is a common operation. Using bool as an index is also commonly needed.
IMO, allowing booleans in these contexts is a good thing (TM) in general, not only for backwards compatibility.
Other languages (C99, C++, Java) name the constants "false" and "true", in all lowercase. In Python, I prefer to stick with the example set by the existing built-in constants, which all use CapitalizedWords: None, Ellipsis, NotImplemented (as well as all built-in exceptions). Python's built-in module uses all lowercase for functions and types only. But I'm willing to consider the lowercase alternatives if enough people think it looks better.
Please make it consistent with Python, not with an arbitrary set of other languages.
For truth testing of a value, one should use "if", e.g. "if x: print 'Yes'", not comparison to a truth value; "if x == True: print 'Yes'" is not only wrong, it is also strangely redundant.
`if x:` is clear, concise, and generic. Adding comparions or an explicit coercion to bool makes it ugly and more difficult to read.
How will bool influence '__nonzero__'? Currently, Python insists that '__nonzero__ should return an int'. Will this be changed to 'should return a bool'?
As that would break existing code, I hope not.