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

Ron Adam rrr at ronadam.com
Sat Mar 3 04:19:33 CET 2007

Collin Winter wrote:
> On 3/2/07, Ron Adam <rrr at ronadam.com> wrote:
>> 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.
> [snip]
>> 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.
> Added consistency:
> - Things related to booleans are operators (bool, not, and, or).


> Added inconsistency:
> - The Bool type does not follow the same naming convention as int,
> float, dict, list, tuple and set.

Ok, so name the type boolean instead.

> - There's now a keyword that has 99% of the same spelling, 

It can be good it has the same *exact* semantics and spelling.  That makes 
it easier to migrate code

> fulfills *fewer* of the same uses-cases

The only difference I can think of is in testing for a bool type.  boolean 
would need to be used instead of bool.

> and has the *exact* same semantics as a built-in constructor/function.

This is not an uncommon thing in python.

    [1,2,3]     <==>  list((1,2,3))
    {'a':1}     <==>  dict(a=1)

    not not n   <==>   bool(n)
    not n       <==>   bool(not n)

    bool n      <==>   boolean(n)
    not n       <==>   boolean(not n)

I suspect the biggest reason against this suggestion is it changes the 
status quo.

As to weather or not it is a keyword,  there is just as strong an argument 
against 'not' not being a keyword as there is for 'bool' being a keyword. 
But the addition of new keywords is historically something to be avoided 
with python.  In this case, I feel boolean types have become such a 
fundamental object in python that this just may be doable.

So with the above changes you have...

   * bool becomes an operator
   * boolean() replaces bool() as a constructor.

   + 1    Things related to booleans are operators (bool, not, and, or).

   + .5   Compiler is able to generate more specific byte code.
          (This is probably only a small benefit so it only gets +.5)

   - 1    it *is* a new keyword, which is something to be avoided.

   + 1    The bool operator is the same as the old constructor
          enabling easy migration.

   - 1    A different name 'boolean' must be used to test for boolean types.

And the total is...  + .5

And If you add in a -1 for anything that changes anything for the sake that 
people just don't like changes in general.  ie... changing the status quo.

It then becomes ...  -.5

Does that sound like a fair evaluation?

<shrug> I tried.  ;-)


More information about the Python-ideas mailing list