Question About Logic In Python

[Ron Adam]

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