[Python-ideas] Revisiting dedicated overloadable boolean operators

[Nicholas Chammas]

On Fri, Aug 3, 2018 at 1:47 PM Todd toddrjen at gmail.com
<http://mailto:toddrjen@gmail.com> wrote:

The operators would be:
>
> bNOT - boolean "not"
> bAND - boolean "and"
> bOR - boolean "or"
> bXOR - boolean "xor"
>
These look pretty ugly to me. But that could just be a matter of
familiarity.

For what it’s worth, the Apache Spark project offers a popular DataFrame
API for querying tabular data, similar to Pandas. The project overloaded
the bitwise operators &, |, and ~ since they could not override the boolean
operators and, or, and not.

For example:

non_python_rhode_islanders = (
    person
    .where(~person['is_python_programmer'])
    .where(person['state'] == 'RI' & person['age'] > 18)
    .select('first_name', 'last_name')
)
non_python_rhode_islanders.show(20)

This did lead to confusion among users
<https://issues.apache.org/jira/browse/SPARK-8568> since people (myself
included) would initially try the boolean operators and wonder why they
weren’t working. So the Spark devs added a warning
<https://github.com/apache/spark/pull/6961/files> to catch when users were
making this mistake. But now it seems quite OK to me to use &, |, and ~ in
the context of Spark DataFrames, even though their use doesn’t match their
designed meaning. It’s unfortunate, but I think the Spark devs made a
practical choice that works well enough for their users.

PEP 335 would have addressed this issue by letting developers overload the
common boolean operators directly, but from what I gather of Guido’s
rejection
<https://mail.python.org/pipermail/python-dev/2012-March/117510.html>, the
biggest problem was that it would have had an undue performance impact on
non-users of boolean operator overloading. (Not sure if I interpreted his
email correctly.)
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180803/76cea595/attachment-0001.html>