[Python-ideas] [Python-ideos] Dedicated overloadable boolean operators

[Jelte Fennema]

Some examples of current practice for SQLAlchemy (an SQL ORM) can be found 
here: http://docs.sqlalchemy.org/en/rel_1_0/orm/tutorial.html#common-filter-operators
An slightly adapted example is this: 

from sqlalchemy import or_, and_
query.filter(or_(User.name == 'ed', and_(User.name == 'wendy', User.age > 
20)))

With the new operators this could simply be rewritten to:
query.filter(User.name == 'ed' || (User.name == 'wendy' && User.age > 20))
This is much clearer in my opinion.

Pandas overloads the binary and and  or operators, which causes the small 
issue that it needs an extra pair of braces around expressions, see 
https://stackoverflow.com/questions/24775648/element-wise-logcial-or-in-pandas 
or http://stackoverflow.com/a/19581644/2570866

This means that this (which selects the rows that either are lower than 
three or equal to five):
df[(df < 3) | (df == 5)]
Can be rewritten to this:
df[df < 3 || df == 5]
This is clearly little advantage, but it also means that there is no need 
to override the binary or and and. That way they can be used for their 
original purpose.

For Numpy the case is again like with SQLAlchemy see 
: https://docs.scipy.org/doc/numpy/reference/generated/numpy.logical_and.html 
and https://docs.scipy.org/doc/numpy/reference/generated/numpy.logical_or.html

I hope this made the use for the overloadable logical and and or operators 
clear. The not operator might be a bit less useful and I'm not sure it's 
needed as much. Currently SQLAlchemy and Pandas overload the "~" (invert) 
operator and Numpy has a function again: 
https://docs.scipy.org/doc/numpy/reference/generated/numpy.logical_not.html 

Lastly, for SQLAlchemy an in operator that does not return a boolean could 
also be useful. I can't think of use cases for the others though and I also 
can't directly think of an operator that would be as clear as the &&, || 
and ! operators.

As for the PEP, I have no problem writing one if this is accepted as a 
useful addition. Also any suggestions and critiques are very welcome of 
course. 

On Monday, 23 November 2015 21:24:23 UTC+1, Emanuel Barry wrote:
>
> Could you provide some links to where this could be useful, and how code 
> could be rewritten? I can see the desire for such a feature, I myself would 
> have liked such an operator or keyword. If you get general approval on this 
> list, you can then move on to write a PEP (as that's what's needed if you 
> wish to add a new keyword and/or operator to the language).
>
> I'm +0 for now, and may change once you provide us with use cases in the 
> wild.
> -Emanuel
>
> ------------------------------
> From: m... at jeltef.nl <javascript:>
> Date: Mon, 23 Nov 2015 20:09:17 +0100
> To: python... at python.org <javascript:>
> Subject: [Python-ideas] [Python-ideos] Dedicated overloadable boolean 
> operators
>
> Hi,
>
> After reading PEP0465 <https://www.python.org/dev/peps/pep-0465/> about 
> the dedicated matrix multiplication I started wondering if the same 
> solution couldn't be applied to boolean operators as well. There currently 
> are a lot of high profile libraries that have their own functions for 
> boolean operators, like Numpy, Pandas or SQLAlchemy. They do this because 
> the current boolean operators can't be overloaded. PEP0335 
> <https://www.python.org/dev/peps/pep-0335/> was created to solve this 
> problem (and makes the problem more clear), but was rejected because it 
> needed changes to the byte code for the boolean operators, which would make 
> them slower. Currently some of these libraries resort to the bitwise 
> operators (at least Pandas), but those don't bind as strong as comparison 
> operators, which means you have to do comparisons like this: (series1 == 2) 
> & (series2 == 3) 
>
> That is why I propose to create new operators just like for matrix 
> multiplication which can be used in libraries that need one. I'm not sure 
> what the operators should look like, but my first guess would be &&, || and 
> ! for and, or and not respectively. 
>
> Is this an idea that sounds reasonable?
>
> Jelte
>
> _______________________________________________ Python-ideas mailing list 
> Python... at python.org <javascript:> 
> https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: 
> http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151123/79e9f330/attachment-0002.html>