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).
Yes
> 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)
Currently:
not not n <==> bool(n)
not n <==> bool(not n)
Alternative:
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.
Consistency:
+ 1 Things related to booleans are operators (bool, not, and, or).
Performance:
+ .5 Compiler is able to generate more specific byte code.
(This is probably only a small benefit so it only gets +.5)
Keyword:
- 1 it *is* a new keyword, which is something to be avoided.
Name:
+ 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. ;-)
_Ron