Re: [Python-ideas] [Python-Dev] bool conversion wart?
Ron Adam wrote:
Ok, so what if... instead of bool being a type, it be a keyword that is just a nicer way to spell 'not not'?
The main benefit of having a bool type is so that its values display as "True" and "False" rather than whatever surrogate values you happen to have used to represent true and false. The fact that bool() can be used canonicalise a truth value is secondary -- the same thing could just as well be achieved by a plain function (as it was before bool became a type). It's an extremely rare thing to need to do in any case. If any change is to be made to bool in 3.0, my preference would be to keep it but make it a separate type.
Are 'and' and 'or' going to be changed in 3.0 to return bool types too?
I very much hope not! Their current behaviour is very useful, and I would hate to lose it. -- Greg
It seems this thread has run it's course on python-dev, but being on the road for several thousand miles and since I've given it some thought during the trip, I'll go ahead and post my own conclusions for the record. This would be a python 3.0 suggestion only I think. Greg Ewing wrote:
Ron Adam wrote:
Ok, so what if... instead of bool being a type, it be a keyword that is just a nicer way to spell 'not not'?
The main benefit of having a bool type is so that its values display as "True" and "False" rather than whatever surrogate values you happen to have used to represent true and false.
This wouldn't change. A bool keyword would still return True or False "bool" objects just as 'not' currently does. It would just complete the set of keywords so we have... and, or --> flow control boolean operators not, bool --> boolean operators Where 'bool' could generate more specific byte code like 'not' already does in some situations.
The fact that bool() can be used canonicalise a truth value is secondary -- the same thing could just as well be achieved by a plain function (as it was before bool became a type). It's an extremely rare thing to need to do in any case.
It seems to me it is the main use, with testing for bool types as the secondary use. All other bool object uses return or compare already created bool objects.
If any change is to be made to bool in 3.0, my preference would be to keep it but make it a separate type.
I think the bool type should still continue to be a subtype of int. The reason for making it it's own type is to limit bools functionality to cases that are more specific in order to avoid some errors. But I feel those errors are not really that common and having bool be a subclass of int increases the situations where bool is useful in a nice way. ie... there are more benefits than consequences.
Are 'and' and 'or' going to be changed in 3.0 to return bool types too?
I very much hope not! Their current behaviour is very useful, and I would hate to lose it.
I agree. I only asked to be sure. A little review: On python-dev a question weather or not bool conversion was a wart was brought up because of an apparent inconsistency of value returned in some cases. It was pointed out that there was no inconsistency, and that the current behavior was correct and consistent, as well as being desirable. However, there are some people who feel there is room for improvement where bool is concerned. I think this unsettled/incomplete feeling is due to a small inconsistency of how bool is used, (rather than what it does), in relation to the 'and', 'or' and 'not' keywords. The 'and' and 'or' keywords return either the left or right values depending on their bool interpretation by comparison methods. This is not a problem, and it is both the expected and desired behavior. * There is both implicit (or equivalent) and explicit bool operations in python. the 'not' keyword returns a bool by calling a numbers __nonzero__ method, or a containers __len__ method which in turn is used to returns either a True or False bool object. There is no bool keyword equivalent except 'not not' which isn't the most readable way to do it. This is because any object can be used as an implicit bool, though there are situations where returning an explicitly constructed bool (True or False) expresses a clearer intent. 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. I believe this is a matter of both how the bool objects True and False came into python and a matter of practicality. Boolean objects are used frequently in loop tests and it is very good that they work as fast as possible. (In the case of 'not' different byte code is generated depending on how it is used.) The 'not' operator proceeded bool, other wise we might have had a not() function or type that returns a bool object in it's place, or bool would have been a keyword working in much the same way as not does now. It appears the use of bools are becoming integrated even more closely with the interpreters byte code, so in my opinion it makes more since to make bool a keyword that works in the same way as 'not', rather than make 'not' a sub-classed constructor, (to bool), that returns a bool object. The only difficulty I see with a bool keyword is the bool type would need to be spelled 'Bool' rather than 'bool'. In most cases this change looks like it would be backwards compatible as well. bool (expresssion) <==> bool expression True and False could then become protected built-in objects like None: True = Bool(1) False = Bool(0) The documents on None say the following. Changed in version 2.4: None became a constant and is now recognized by the compiler as a name for the built-in object None. Although it is not a keyword, you cannot assign a different object to it. PEP 3100 only says... * None becomes a keyword [4] (What about True, False?) The reference [4] lists compatibility to python 2.3 as a reason for not protecting True and False, but it seems the general consensus from various threads I've examined is to have them protected. http://mail.python.org/pipermail/python-dev/2004-July/046294.html Making True and False protected objects along with making bool a keyword may have some performance benefits since in many cases the compiler could then directly return the already constructed True and False object instead of creating new one(s). [it may already do this under the covers in some cases(?)] This may or may not effect the case where 'while 1:' is faster than 'while True:'. It is also helpful to look at some byte code examples to compare how 'not', 'not not' and bool() work in different situations and see how it may be changed if bool where a keyword and True and False become protected objects. It may be that in some (common?) cases the C code for some byte codes and objects could return True and False references directly. In my opinion this really just finishes up a process of change that is already started and ties up the loose ends. It does not change what bool(), True, False, and not do in any major way. It may create opportunities for further optimizations. Cheers, Ron
Ron Adam wrote:
Greg Ewing wrote:
The fact that bool() can be used canonicalise a truth value is secondary
It seems to me it is the main use, with testing for bool types as the secondary use.
What I meant was that this usage is not reason enough on its own for bool to be a type. Given that bool is already a type, it's convenient for its constructor to also be the canonicalising function. It's secondary as a reason for making bool a type, not in the sense of how it's normally used.
having bool be a subclass of int increases the situations where bool is useful in a nice way.
I still think that most of those uses could be covered by giving bool an __index__ method.
Making True and False protected objects along with making bool a keyword may have some performance benefits since in many cases the compiler could then directly return the already constructed True and False object instead of creating new one(s). [it may already do this under the covers in some cases(?)]
I believe that True and False are treated as singletons, so this should always happen. I don't see anywhere enough benefit to be worth making a bool keyword. Optimisation of access to True and False is probably better addressed through a general mechanism for optimising lookups of globals, although I wouldn't object if they were treated as reserved identifiers a la None. Summary of my position on this: +0 making bool a separate type with __index__ in 3.0 +0 treating True and False like None -1 bool keyword -- Greg
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
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 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.
def foo(x): ... return (not not x) != bool(x) ... dis.dis(foo) 2 0 LOAD_FAST 0 (x) 3 UNARY_NOT 4 UNARY_NOT 5 LOAD_GLOBAL 0 (bool) 8 LOAD_FAST 0 (x) 11 CALL_FUNCTION 1 14 COMPARE_OP 3 (!=) 17 RETURN_VALUE
In this case the lines... 5 LOAD_GLOBAL 0 (bool) 8 LOAD_FAST 0 (n) 11 CALL_FUNCTION 1 Would be replaced by... 5 LOAD_FAST 0 (n) 6 UNARY_BOOL The compiler could also replace UNARY_NOT, UNARY_NOT pairs with a single UNARY_BOOL. There may be other situations where this could result in different more efficient byte code as well. _Ron
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)). Changing "bool(x)" to "bool x" introduces a much larger inconsistency between bool and the other built-in types.
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? Collin Winter
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
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
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
Ron Adam <rrr@ronadam.com> wrote:
So I have no problem if it's ruled out on the grounds that 'there is not sufficient need'
Ok. YAGNI. Seriously. The performance advantage in real code, I guarantee, isn't measurable. Also, the inconsistancy is subjective, and I've never heard anyone complain before. - Josiah
Josiah Carlson wrote:
Ron Adam <rrr@ronadam.com> wrote:
So I have no problem if it's ruled out on the grounds that 'there is not sufficient need'
Ok. YAGNI. Seriously. The performance advantage in real code, I guarantee, isn't measurable. Also, the inconsistancy is subjective, and I've never heard anyone complain before.
- Josiah
You are right. It's more cosmetic than actual. I basically said that from the start. Not as a direct complaint, no. It turns up more as a misunderstanding of how 'and' and 'or' work or a misunderstanding why bool returns what it does instead of what someone thinks it should, as in the thread that started this last week. This addresses that in a subtle indirect way by redefining bool as an operator. Weather or not it would actually improve the ease of understanding how python uses and interacts with boolean types and operators, I'm really not sure. As far as performance gain, I was thinking that in combination with making True and False constants, it might be greater. But it may very well not be. Maybe sometime in the near future I will try to test just how much of a difference it could make. In any case the making of True and False into constants is still an open python 3k issue. This was more exploratory and since nobody else jumped in and took it up, it seems it would be un-popular as well. But it's here for the record in any case. Cheers, Ron
Josiah Carlson wrote:
Ron Adam <rrr@ronadam.com> wrote:
So I have no problem if it's ruled out on the grounds that 'there is not sufficient need'
Ok. YAGNI. Seriously. The performance advantage in real code, I guarantee, isn't measurable.
It is measurable, but the total average gain would not be substantial only because of it being a relatively rare operation. The most common use of bool() seems to be in returning a bool value. return bool(exp) A few timeit tests... The bool constructor: $ python2.5 -m timeit -n 10000000 'bool(1)' 10000000 loops, best of 3: 0.465 usec per loop $ python2.5 -m timeit -n 10000000 'bool("a")' 10000000 loops, best of 3: 0.479 usec per loop $ python2.5 -m timeit -n 10000000 'bool([1])' 10000000 loops, best of 3: 0.697 usec per loop A bool operator would have the same (or faster) speed as the 'not' operator: $ python2.5 -m timeit -n 10000000 'not 1' 10000000 loops, best of 3: 0.165 usec per loop $ python2.5 -m timeit -n 10000000 'not "a"' 10000000 loops, best of 3: 0.164 usec per loop $ python2.5 -m timeit -n 10000000 'not [1]' 10000000 loops, best of 3: 0.369 usec per loop The real gain is dependent on how and where it is used of course. In most cases 'not not x' would still be much faster than bool(x). Its nearly as fast as a single 'not' but really isn't the most readable way to do it. $ python2.5 -m timeit -n 10000000 'not not 1' 10000000 loops, best of 3: 0.18 usec per loop $ python2.5 -m timeit -n 10000000 'not not "a"' 10000000 loops, best of 3: 0.185 usec per loop $ python2.5 -m timeit -n 10000000 'not not [1]' 10000000 loops, best of 3: 0.381 usec per loop The following may be an indication of how much speed difference may still be gained in other related situations such as flow control or comparisons where bool values are used implicitly. $ python2.5 -m timeit -n 10000000 'if "a": pass' 10000000 loops, best of 3: 0.0729 usec per loop $ python2.5 -m timeit -n 10000000 'if not "a": pass' 10000000 loops, best of 3: 0.17 usec per loop $ python2.5 -m timeit -n 10000000 'if bool("a"): pass' 10000000 loops, best of 3: 0.486 usec per loop In the case of a bool operator, it's not a major issue because of how rarely it's actually used. Cheers, Ron
participants (4)
-
Collin Winter -
Greg Ewing -
Josiah Carlson -
Ron Adam