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

[Michael Selik]

As I think of people's reactions to seeing & and | for the first time, the
typical response is, "What do you mean by bitwise?" Not, "Why are you using
bitwise operators for non-bitwise operations?" Interestingly, no one in
this thread seems to have a problem with ``&`` and ``|`` for set
intersection and union. The primary complaint is that NumPy users
instinctively reach for ``and``/``or`` and then forget the operator
precedence of ``&``/``|``.


On Mon, Nov 23, 2015 at 9:09 PM Jelte Fennema <me at jeltef.nl> wrote:

> On 24 November 2015 at 02:44, Michael Selik <mike at selik.org> wrote:
>
>> Why hasn't SQLAlchemy gone the route of NumPy with overloaded operators?
>>
> It seems I was wrong about that, they apparently do:
> http://stackoverflow.com/a/14185275/2570866
>

Using pipe and ampersand looks readable. The use of bitwise operators for
overloading and/or/not seems standard for many objects, in standard library
and major projects. In fact, I use those operators as logical far more
often than as bitwise. I'd bet a great number of NumPy users in the science
community are completely unaware of their bitwise effects.


I'd put that in the category of parentheses tax along with the print
>> function and old style % string interpolation.
>
> This seems like a bit of a weird argument since the parentheses for the
> print function are put there for a reason (see PEP3105) and the old style %
> string interpolation will be replaced by the new format string literal.
>

I picked ``print`` as an example to show that requiring parens is fine. I
picked string interpolation as an example because the ``.format`` solution
also accepted parens as necessary. The rationale for f-string syntax (as
written in the PEP) does not complain about parens but instead mentions
that they will be necessary inside the string in several circumstances,
like lambdas.

Adding yet another operator would make Python harder to learn and read.
>> Even if you advertise a new operator, many libraries will be slow to change
>> and we'll have 3 different techniques to teach.
>
> I don't think that much confusion will arise, since the normal way is to
> to use is the short `and` version. Only in libraries where it would be
> explicitly told the new operator would be used. It would also do away with
> the confusion about why and cannot be overridden and why the precedence of
> the & operator is "wrong".
>

That precedence issue doesn't cause problems when teaching, in my
experience. People accept readily that there's issues with operator
precedence. On the other hand, they have trouble reading code that uses an
older style (perhaps using ``&``) instead of the newer style that they
learned (the hypothetical ``&&``). Even the switch between ``%``
interpolation and ``.format`` is still causing problems in large
organizations.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151124/1ade5c2b/attachment.html>