[Python-ideas] Revisiting dedicated overloadable boolean operators

Todd toddrjen at gmail.com
Fri Aug 3 13:46:39 EDT 2018


Coming back to the previous discussion about a new set of overloadable
boolean operators [1], I have an idea for overloadable boolean operators
that I think might work.  The idea would be to define four new operators
that take two inputs and return a boolean result based on them.  This
behavior can be overridden in appropriate dunder methods.  These operators
would have similar precedence to existing logical operators.  The operators
would be:

bNOT - boolean "not"
bAND - boolean "and"
bOR - boolean "or"
bXOR - boolean "xor"

With corresponding dunder methods:

__bNOT__ and _rbNOT__ (or __r_bNOT__)
__bAND__ and _rbAND__ (or __r_bAND__)
__bOR__ and _rbOR__ (or __r_bOR__)
__bXOR__ and _rbXOR__ (or __r_bXOR__)

The basic idea is that the "b" is short for "boolean", and we change the
rest of the operator to upercase to avoid confusions with the existing
operators.  I think these operators would be preferably to the proposals so
far (see [1] again) for a few reasons:

  1. They are not easy to mistake with existing operators.  They are
clearly not similar to the existing bitwise operators like & or |, and
although they are clearly related to the "not", "and", and "or" I think
they are distinct enough that it should not be easy to confuse the two or
accidentally use one in place of the other.

   2. They are related to the operations they carry out, which is also an
advantage over the existing bitwise operators.

   3. The corresponding dunder methods (such as __bAND__ and _rbAND__) are
obvious and not easily confused with anything else.

   4. The unusual capitalization means they are not likely to be used much
in existing Python code.  It doesn't fall under any standard capitalization
scheme I am aware of.

   5. At least for english the capitalization means they are not easy to
confuse with existing words.  For example Band is a word, but it is not
likely to be capitalized as bAND.

As to why this is useful, the overall problem is that the current logical
operators, like and, or, and not, cannot be overloaded, which means
projects like numpy and SQLAlchemy instead have to (ab)use bitwise
operators to define their own boolean operations (for example elementwise
"and" in numpy arrays).  This has a variety of problems, such not having
appropriate precedence leading to precedence errors being common, and the
simple fact that this precludes them from using the bitwise operators for
bitwise operations.

There was a proposal to allow overloading boolean operators in Pep-335 [2],
but that PEP was rejected for a variety of very good reasons.  I think none
of those reasons (besides the conversation fizzling out) apply to my
proposal.

So the alternative proposal that has been floating around is to instead
define new operators specifically for this.  Although there seemed to be
some support for this in principle, the actually operators so far have not
met with much enthusiasm.  So far the main operators proposed so far seem
to be:

1. Double bitwise operators, such as && and ||.  These have the
disadvantage of looking like they should be a type of bitwise operator.

2. the existing operators, with some non-letter character at the front and
back, like ".and.".  These have the advantage that they are currently not
valid syntax in most cases, but I think are too similar to existing logical
operators, to easy to confuse, and it is not immediately obvious in what
way they should differ from existing operators.  They also mean different
things in other languages.

So I think my proposal addresses the main issues raised with existing
proposals, but has the downside that it requires new keywords.

Thoughts?

[1] https://mail.python.org/pipermail/python-ideas/2015-November/037207.html
[2] https://www.python.org/dev/peps/pep-0335/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180803/171b2d4c/attachment.html>


More information about the Python-ideas mailing list