[Python-ideas] Revisiting dedicated overloadable boolean operators

[Neil Girdhar]

This doesn't work because the logical Boolean operators short circuit in 
Python.  So you could not even define these operators for the regular 
Python types.  Your two examples numpy and SQLAlchemy don't want this 
short-circuiting behavior, so you would never want to write anything like

(some_array or some_other_array)

The reader of this code might imagine that there is some short circuiting 
or conversion to Boolean.

The essential problem here is that you want a nicer way to create symbolic 
graphs with Boolean operators.  But the general problem is that Python 
always has wrinkles when creating symbolic graphs.  Besides numpy 
conditions and SQLAlchemy, sympy and tensorflow also build symbolic 
graphs.  They also struggle with succinctness.  You will never get the 
symbolic graph to look just like pseudocode the way pure Python does. 

On Friday, August 3, 2018 at 1:48:02 PM UTC-4, Todd Jennings wrote:
>
> 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/20180806/00b9d43b/attachment-0001.html>