It seems this thread has run it's course on python-dev, but being on the road for several thousand miles and since I've given it some thought during the trip, I'll go ahead and post my own conclusions for the record. This would be a python 3.0 suggestion only I think. Greg Ewing wrote:
Ron Adam wrote:
Ok, so what if... instead of bool being a type, it be a keyword that is just a nicer way to spell 'not not'?
The main benefit of having a bool type is so that its values display as "True" and "False" rather than whatever surrogate values you happen to have used to represent true and false.
This wouldn't change. A bool keyword would still return True or False "bool" objects just as 'not' currently does. It would just complete the set of keywords so we have... and, or --> flow control boolean operators not, bool --> boolean operators Where 'bool' could generate more specific byte code like 'not' already does in some situations.
The fact that bool() can be used canonicalise a truth value is secondary -- the same thing could just as well be achieved by a plain function (as it was before bool became a type). It's an extremely rare thing to need to do in any case.
It seems to me it is the main use, with testing for bool types as the secondary use. All other bool object uses return or compare already created bool objects.
If any change is to be made to bool in 3.0, my preference would be to keep it but make it a separate type.
I think the bool type should still continue to be a subtype of int. The reason for making it it's own type is to limit bools functionality to cases that are more specific in order to avoid some errors. But I feel those errors are not really that common and having bool be a subclass of int increases the situations where bool is useful in a nice way. ie... there are more benefits than consequences.
Are 'and' and 'or' going to be changed in 3.0 to return bool types too?
I very much hope not! Their current behaviour is very useful, and I would hate to lose it.
I agree. I only asked to be sure. A little review: On python-dev a question weather or not bool conversion was a wart was brought up because of an apparent inconsistency of value returned in some cases. It was pointed out that there was no inconsistency, and that the current behavior was correct and consistent, as well as being desirable. However, there are some people who feel there is room for improvement where bool is concerned. I think this unsettled/incomplete feeling is due to a small inconsistency of how bool is used, (rather than what it does), in relation to the 'and', 'or' and 'not' keywords. The 'and' and 'or' keywords return either the left or right values depending on their bool interpretation by comparison methods. This is not a problem, and it is both the expected and desired behavior. * There is both implicit (or equivalent) and explicit bool operations in python. the 'not' keyword returns a bool by calling a numbers __nonzero__ method, or a containers __len__ method which in turn is used to returns either a True or False bool object. There is no bool keyword equivalent except 'not not' which isn't the most readable way to do it. This is because any object can be used as an implicit bool, though there are situations where returning an explicitly constructed bool (True or False) expresses a clearer intent. Interpretation: The "small" inconsistency (if any) here is the 'not' keyword vs the 'bool()' constructor. They pretty much do the same thing yet work in modestly different ways. I believe this is a matter of both how the bool objects True and False came into python and a matter of practicality. Boolean objects are used frequently in loop tests and it is very good that they work as fast as possible. (In the case of 'not' different byte code is generated depending on how it is used.) The 'not' operator proceeded bool, other wise we might have had a not() function or type that returns a bool object in it's place, or bool would have been a keyword working in much the same way as not does now. It appears the use of bools are becoming integrated even more closely with the interpreters byte code, so in my opinion it makes more since to make bool a keyword that works in the same way as 'not', rather than make 'not' a sub-classed constructor, (to bool), that returns a bool object. The only difficulty I see with a bool keyword is the bool type would need to be spelled 'Bool' rather than 'bool'. In most cases this change looks like it would be backwards compatible as well. bool (expresssion) <==> bool expression True and False could then become protected built-in objects like None: True = Bool(1) False = Bool(0) The documents on None say the following. Changed in version 2.4: None became a constant and is now recognized by the compiler as a name for the built-in object None. Although it is not a keyword, you cannot assign a different object to it. PEP 3100 only says... * None becomes a keyword [4] (What about True, False?) The reference [4] lists compatibility to python 2.3 as a reason for not protecting True and False, but it seems the general consensus from various threads I've examined is to have them protected. http://mail.python.org/pipermail/python-dev/2004-July/046294.html 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(?)] This may or may not effect the case where 'while 1:' is faster than 'while True:'. It is also helpful to look at some byte code examples to compare how 'not', 'not not' and bool() work in different situations and see how it may be changed if bool where a keyword and True and False become protected objects. It may be that in some (common?) cases the C code for some byte codes and objects could return True and False references directly. In my opinion this really just finishes up a process of change that is already started and ties up the loose ends. It does not change what bool(), True, False, and not do in any major way. It may create opportunities for further optimizations. Cheers, Ron