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. 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