<div dir="ltr"><div>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:</div><div><br></div><div>bNOT - boolean "not"<br></div><div>bAND - boolean "and"</div><div>bOR - boolean "or"</div><div>bXOR - boolean "xor"</div><div><br></div><div>With corresponding dunder methods:</div><div><br></div><div>__bNOT__ and _rbNOT__ (or __r_bNOT__)<div></div><div>__bAND__ and _rbAND__ (or __r_bAND__)<div></div><div>__bOR__ and _rbOR__ (or __r_bOR__)</div></div><div><div>__bXOR__ and _rbXOR__ (or __r_bXOR__)</div></div></div><div></div><div><br></div><div>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:</div><div><br></div><div>  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.</div><div><br></div><div>   2. They are related to the operations they carry out, which is also an advantage over the existing bitwise operators.</div><div><br></div><div>   3. The corresponding dunder methods (such as __bAND__ and _rbAND__) are obvious and not easily confused with anything else.</div><div><br></div><div>   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.<br></div><div><br></div><div>   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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>1. Double bitwise operators, such as && and ||.  These have the disadvantage of looking like they should be a type of bitwise operator.</div><div><br></div><div>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.</div><div><br></div><div>So I think my proposal addresses the main issues raised with existing proposals, but has the downside that it requires new keywords.<br></div><div><br></div><div>Thoughts?<br></div><div><br></div><div>[1] <a href="https://mail.python.org/pipermail/python-ideas/2015-November/037207.html">https://mail.python.org/pipermail/python-ideas/2015-November/037207.html</a></div><div>[2] <a href="https://www.python.org/dev/peps/pep-0335/">https://www.python.org/dev/peps/pep-0335/</a><br></div></div>