Question About Logic In Python
rrr at ronadam.com
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
person.name = (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.
person.name = (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
> http://en.wikipedia.org/wiki/Boolean_algebra 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
More information about the Python-list