Mark Dickinson <> added the comment:

> and a minimal representation of boolean logic operations that will seem 
> natural to anyone, don't you think ?

I'm afraid I don't. :-(

Issue 1: this ABC doesn't seem a good match for Python bools. If I have a 
bool-like object in a piece of code, my main expectations of that object would 
be that (a) it can be interpreted in a boolean context (e.g., the condition of 
an if statement, a while statement, an if-else expression, a std. lib. call 
that expects a bool, etc.), and (b) it can be combined with other bool-likes 
via `and`, `or` and `not`. All I need for (a) and (b) to work is that 
`__bool__` is defined. The *bitwise* operations provided by `__and__`, `__or__` 
and friends are irrelevant for these purposes, and for Python's bool they exist 
mainly because bool is a subclass of int, and not to provide logical boolean 
operations. (NumPy's take on this is a bit different, because of the issues 
involved with interpreting an array of booleans in boolean context.)

Issue 2: an interface that includes `|`, `&` and `^` but not `~` seems 
incomplete. If I *am* aiming to do bitwise operations with an object (as 
opposed to logical operations) then I'd probably expect `~` to be present. 
(Admittedly, there are cases that support `|`, `^` and `&` but not `~`, like 

Perhaps there's a place for an interface that declares that an object supports 
the *bitwise* operators: `|`, `&`, `^` and `~`. We *do* have more than one 
concrete class here that would implement such an interface: Python's integer 
types, NumPy's integer types, NumPy's `bool_` type, potentially other things 
that resemble fixed-length bit-strings (like IP addresses or collections of 
flags). But I wouldn't call such an interface "Boolean", and wouldn't expect 
Python's built-in bool type to be registered as supporting that interface.

So overall, call me -1 on this proposal.


Python tracker <>
Python-bugs-list mailing list

Reply via email to