Question About Logic In Python

Ron Adam rrr at
Thu Sep 22 03:45:42 CEST 2005

Steven D'Aprano wrote:

> Ah, that's a good example, thanks, except I notice you didn't actually
> cast to bool in them, eg: (min < value < max) * value

It wasn't needed in these particular examples.  But it could be needed 
if several comparisons with 'and' between them are used.

It just seems odd to me that:

     3 and 2 and 1  -> 1
     1 and 2 and 3  -> 3

But that may be because I learned boolean algebra as part of an 
electronics logic (computer tech) course dealing with gates in the early 

>>In boolean math it is useful to add and subtract.
>> >>> a = b = True
>> >>> a + b
>>2                   # Non boolean result.

> I presume you mean Boolean algebra by "Boolean math". I have to disagree
> with you there. It is *not* useful to do addition, subtraction,
> multiplication or division in Boolean algebra. ....

Yes, but not quite as strict as True BA would be and not with the strict 
type checking other languages have.

> I'm not saying that it can't be useful to treat Booleans as if they were
> the integers 0 and 1, but in mathematics Booleans are abstract values
> distinct from the integers (even when they use the symbols 0 and 1) and
> the concept "True plus True is two" is meaningless.
> It is useful to read the comments here:

Thanks and the PEP link from there was useful too.

> eg "Python's Booleans were not added for the sake of strict type-checking.
> A very strict language such as Pascal would also prevent you performing
> arithmetic with Booleans, and would require that the expression in an if
> statement always evaluate to a Boolean result."

It doesn't need to be that strict.  But a few changes could resolve and 
reduce the chance of errors especially for beginners, while not limiting 
more advanced uses.  These would be Python 3k changes most likely if at all.

     1.  'and', 'or', and 'not' always return bool values.

Lots of discussion on this one already. From the look of it, I don't 
think it will change.  But Guido seemed to suggest its possible with the 
addition of a trinary operation.  But even with that it wouldn't be done 
any time soon.

     2.  bool == value to be the same as bool == value.__nonzero__()

By doing this comparisons with Bool types will match the behavior of if 
conditions without restricting if to strictly bools.

     3.  Math with bools as both arguments should return bools.

This wouldn't prevent adding bools and ints, or doing other operations 
on them.  But bools would remain bool types until an operation with a 
non bool type.

     True * True  -> True  instead of 1
     True * False  -> False  instead of 0
     False * True -> False  instead of 0
     False * False -> False  instead of 0
     True * 10 -> 10
     False * 10 -> 0
     True * 0 -> 0

     True + True -> True instead of 2  **changed**
     True + False -> True instead of 1
     False + True -> True instead of 1
     False + False -> False instead of 0
     True + 1 = 2
     False + 0 = 0

     -True -> False instead of -1  **changed**
     -False -> True instead of 0   **changed**
     1-True -> 0
     1-False -> 1
     2-True -> 1
     2-False -> 2
     True-1 -> 0
     False-1 -> -1

Notice there is only three places above where the change would be 
significantly different than now.  All other cases would just exchange 
True of 1 or False for 0.

Some operation would need a trinary operation in place of the current 
and/or. = (if name then name else 'default name')

Not my favorite syntax, but I can live with it.  It might be possible to 
have a short form. = (name else 'default name')

>>Should bool type act like bools as expressed here?
> That is only one possible Boolean algebra, the simplest one. Strictly
> speaking, Booleans aren't limited to two values. See
> for more detail.

I look at those earlier and was surprised at how complex some Boolean 
algebra concepts were.  Interesting though, and I'll probably go back 
and study it a bit more.

> Python's bools aren't Booleans. They are merely aliases for 0 and 1.

Yes, and according to the PEP they were introduced to help reduce 
errors.  ;-)


More information about the Python-list mailing list