Collin Winter wrote:
On 3/2/07, Ron Adam <rrr@ronadam.com> wrote:
Collin Winter wrote:
On 3/2/07, Ron Adam <rrr@ronadam.com> wrote:
Josiah Carlson wrote:
Ron Adam <rrr@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