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). Added inconsistency: - The Bool type does not follow the same naming convention as int, float, dict, list, tuple and set. - There's now a keyword that has 99% of the same spelling, fulfills *fewer* of the same uses-cases and has the *exact* same semantics as a built-in constructor/function. That's a bizarre trade-off. -1000. Collin Winter