Steve Holden wrote: > Ron Adam wrote: >> >> 2. Expressions that will be used in a calculation or another >> expression. >> > By which you appear to mean "expressions in which Boolean values are > used as numbers".
Or compared to other types, which is common. >> This matters because if you aren't careful your results may not be >> what you expect. >> > Well yes, but then I wouldn't necessarily expect good results if I tried > to use a nail file as a tyre-lever, either. If you abuse the intent of > anything sufficiently you should expect trouble. But then, you seem to > like trouble ;-) Steve... You seem to agree, but think if any one has a problem with this, it's a misuse or an abuse. Ok. fair enough. Its not so much I like trouble, It's more that I tend to get stuck on contradictions and inconsistencies. They bug me. (sometimes I bug myself as well) ;-) >> >>> True * True >> 1 # Why not return True here as well? >> > Why not return 42? Why not return a picture of a banana? My question still stands. Could it be helpful if bools were preserved in more cases than they are now? My feelings is that it isn't needed as long as you strictly use your own modules, functions, and classes, and can depend on the behavior you decide on. But if you are using routines and object written by others, you can't always be sure if a values should be treated as a bool or as an integer. Preserving bools when possible, may help in that regard. >> This is like adding two integer types and getting a float. >> > No it isn't. It's like trying to multiply April 2 1994 by June 5 2005. > The operation isn't defined. So you choose an arbitrary definition and > say "it would be nice if it worked like this instead of how it actually > does work". Sure, but if we didn't suggest changes, then nothing would change. We would just have extremely detailed documentation of everything and strict rules of use so that we don't misuse them. ;-) > When in fact it doesn't really "work" at all, except for the most > tenuous possible value of "work". It's an accident, because Guido > decided that least code breakage was good when Booleans were introduced. Good point, but it could be changed in Python 3000 since it will drop the backwards compatible requirement. This doesn't mean that it should though. The reasons for doing so still need to be sufficient. >> There's the possibility of adding two (normally) True values and >> getting a False result. >> >> >>> a = True >> >>> b = -1 >> >>> a + b # True_value + True = False_value >> 0 >> > Which is yet another reason why it makes absolutely no sense to apply > arithmetic operations to Boolean values. Again you agree, yet disagree. Ok, I see your point about breaking code, but should this be changed, either throw an exception or by changing to a boolean operation in Python 3000? You already consider it an abuse. > You are, of course, ignoring the huge amount of code breakage this > little change you'd find so convenient would cause. I'm not suggesting anything be changed before Python 3000 which has as a purpose of changing things that haven't been changed because of backwards compatibility. And I don't think I'm the only one who has suggested these. >> On one hand these seem like little things, but little things is >> sometimes what will bite you the hardest as they are more likely to >> get by your guard. >> > Kindly think again about the vast number of times that Python > programmers have relied on the documented property of "and", which says > that it returns the left operand (without evaluating the right one) > unless the left operand is equivalent to False, in which case it returns > the right operand. The shortcut behavior would still work, but the returned values would be either True or False. I agree the above is useful behavior, but I also see the boolean behavior as desirable. I would like both in clear and separate contexts if possible. Guido said the other day on python-dev, he would consider having 'and' and 'or' return True and False in order to reduce bugs, if a trinary was also added. It's not as short to type, but the same functionality would still be present in the language. Another possibility would be to just add bool operators '||' and '&&' which would always return True and False and leave 'and' and 'or' as they are. > You talk about "least surprises" and "in my opinion" as though your > opinions are the only ones that anyone would dream of holding. This is > in itself quite surprising to me. No, "in my opinion" means exactly that, It's my personal opinion. You are free and welcome to express "your opinion" as well. And "least surprises" is, I believe, a good thing to strive for. Weather or not this would fit that I'm not sure. It's quite possible that some of these changes would create more surprises not less. Also these ideas aren't mine, they are fairly standard concepts that other languages use as well, nothing really new here. Cheers, Ron -- http://mail.python.org/mailman/listinfo/python-list
