Ron Adam wrote:
Greg Ewing wrote:
The fact that bool() can be used canonicalise a truth value is secondary
It seems to me it is the main use, with testing for bool types as the secondary use.
What I meant was that this usage is not reason enough on its own for bool to be a type. Given that bool is already a type, it's convenient for its constructor to also be the canonicalising function. It's secondary as a reason for making bool a type, not in the sense of how it's normally used.
having bool be a subclass of int increases the situations where bool is useful in a nice way.
I still think that most of those uses could be covered by giving bool an __index__ method.
Making True and False protected objects along with making bool a keyword may have some performance benefits since in many cases the compiler could then directly return the already constructed True and False object instead of creating new one(s). [it may already do this under the covers in some cases(?)]
I believe that True and False are treated as singletons, so this should always happen.
I don't see anywhere enough benefit to be worth making a bool keyword.
Optimisation of access to True and False is probably better addressed through a general mechanism for optimising lookups of globals, although I wouldn't object if they were treated as reserved identifiers a la None.
Summary of my position on this:
+0 making bool a separate type with __index__ in 3.0 +0 treating True and False like None -1 bool keyword