> 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 sets.)

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.