[Python-ideas] bool keyword: (was [Python-Dev] bool conversion wart?)
Ron Adam
rrr at ronadam.com
Fri Mar 2 20:57:21 CET 2007
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
More information about the Python-ideas
mailing list