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

[Jelte Fennema]

On 24 November 2015 at 10:14, Michael Selik <mike at selik.org> wrote:

> 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 ``&``/``|``.
>


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 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.
>
> 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.
>
> I get your points that it is bad to confuse people with even more and/or
operators they have to learn. But I think it's weird that you are saying
that people accept the wrong operator precedence readily, even though
before you said you do it wrong yourself constantly. This is also why I
think the set intersection and union are not a problem is because the
operator precedence is correct there.

Your point that the problem is mostly that the old code will still be usin
the ``&`` operator, which could confuse people is true. But I also think
that would eventually disappear, which would make Python better in the
future.

Another thing is that it seems some people are worried about the form of
the new operators. Some options (which don't use the C style &&, because
that would indeed cause confusion):
.and.
*and*
+and+
%and%
@and@
?and?
^and^
<and>
{and}
(and)
[and]
|and|
:and:
_and_ (could currently be a variablename)
en (the Dutch version)

Some of these could also be used with just one special character, like
@and, but I think the surrounded ones look more visually pleasing. These
are just a couple of examples and some of them seem fine to me. I do think
that it is important though to not focus on the form already. It seems
better to first figure out if the new operators would not confuse the
newcomers to much in whatever form they come.


On 24 November 2015 at 10:14, Michael Selik <mike at selik.org> wrote:

> 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/c0fffde5/attachment-0001.html>