[Python-ideas] bool keyword: (was [Python-Dev] bool conversion wart?)

[Ron Adam]

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