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

[Ron Adam]

Collin Winter wrote:
> On 3/2/07, Ron Adam <rrr at ronadam.com> wrote:
>> Josiah Carlson wrote:
>> > Ron Adam <rrr at ronadam.com> wrote:
>> >> 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.
>> >
>> > Maybe I'm missing something, but is there a place where the 
>> following is
>> > true?
>> >
>> >     (not not x) != bool(x)
>> >
>> > I can't think of any that I've ever come across.
>> >
>> >  - Josiah
>>
>> I don't think you are missing anything.  I did say it was a *small*
>> inconsistency in how they are used in relation to 'and', 'or' and 'not'.
>> ie.. a constructor vs a keyword in a similar situation.
> 
> 'and', 'or' and 'not' are operators (and hence keywords) because
> making them functions is incredibly ugly: and(or(a, b), not(c)).

I agree.

> Changing "bool(x)" to "bool x" introduces a much larger inconsistency
> between bool and the other built-in types.

A bool keyword would not be a built-in type but be an operator just like 
'and', 'or', and 'not'.  So it would be even more consistent.

Bool() with a capital 'B' would be the built in type and only the very 
*tiny* naming inconsistency of the capital 'B' would exist in relation to 
'int' and the other built_in types.

So I think this adds more consistency than it does inconsistency.

The performance benefits are a nice additional bonus. And how much that is 
(if it is a deciding factor) would need to be determined.


Note: The Bool() type as a constructor would hardly ever be needed with the 
presence of a bool operator.  So the capital "B" probably won't be a major 
problem for anyone.  If it is, it could be called boolean() instead.


>> And I also pointed out it doesn't change what they do, it has more to do
>> with how they work underneath and that there may be some benefits in
>> changing this.
> 
> So the main reason is for optimization? Are you really calling bool()
> frequently in inner-loop code? Is a profiler telling you that bool()
> is a bottleneck in your applications?

I'm not using it that way my self, but you are correct that the idea needs 
to be tested.

When 'not' is used with 'if' and 'while' it results in specific byte code 
to that situation instead of UNARY_NOT.  A bool operator may also work that 
way in other similar situations.  So it may be a greater benefit than 
expected.  (?)  It needs research I admit.

And I do realize "if bool x:" and "while bool x:" would not be the 
preferred spelling and would result in the same *exact* byte code as "if 
x:" and "while x:" I believe.


This was a response to the expressed desire to change bool started in 
python-dev.  Ie... a question and some follow up messages suggesting other 
possibly greater changes in semantics than this.  So it appears there is 
some consensus that there is something that could be changed, but just what 
wasn't precisely determined or agreed on.  After thinking on it some this 
is the best I could come up with.  ;-)

Consider this as 1 part aesthetics, .5 part performance.  And yes these 
changes are *minor*.  I've already stated that in quite a few places now. 
It's the type of thing that could be changed in python 3000 if desired, but 
doesn't need to be changed if it is felt it shouldn't be changed.

So I have no problem if it's ruled out on the grounds that 'there is not 
sufficient need', or on grounds that "it's incorrect" in some other way.

;-)

_Ron