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

[Chris Barker]

>
> 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?"
>>>
>>
agreed -- but unfortunately, numpy may be one place where people really do
want bitwise operations sometimes -- and it's way too late now to re-define
them anyway.


> Interestingly, no one in this thread seems to have a problem with ``&``
>>> and ``|`` for set intersection and union.
>>>
>>
I'd say that's because for sets, it would have been a very rare case to do
bitwise operations -- I'm sure I lack imagination, but I can't think of
even one case where it would make sense. So why not re-use them?

The primary complaint is that NumPy users instinctively reach for
>>> ``and``/``or`` and then forget the operator precedence of ``&``/``|``.
>>>
>>
well, that is an issue, though I think the fact that you can only use & |
when you want  "and" "or" when it happens to make sense -- i.e. for boolean
arrays, is the bigger problem. Also, newbies will either not think to use
them, or will see them in code and think they ARE another way to spell and
and or.

It also doesn't allow element-wise short circuiting behavior. you get:

In [*2*]: np.array([0,1,2,3]) &  np.array([3,2,1,0])

Out[*2*]: array([0, 0, 0, 0])
when you want:

In [*3*]: [ a and b for a,b in zip([0,1,2,3], [3,2,1,0])]

Out[*3*]: [0, 2, 1, 0]
oh, and this:

In [*4*]: np.array([0,1,2,3]) |  np.array([3,2,1,0])

Out[*4*]: array([3, 3, 3, 3])
would surely confuse people that don't "get" what bitwise means, even
though it results in teh same thing in a boolean context:

In [*5*]: (np.array([0,1,2,3]) |  np.array([3,2,1,0])).astype(np.bool)

Out[*5*]: array([ True,  True,  True,  True], dtype=bool)

Honestly, I'm not sure element-wise short circuiting is desired, but it
would be nice to be consistent about that.

As for precedence, it's a annoying, but at least in my experience, the very
first test case fails, and then I remember to add the parens.

As for the more and more operators issue -- for the most part, this would
be used for special purposes -- most people wouldn't even notice there were
there, and numpy users might well think it' s special numpy thing (same for
SQLAlchemy folks, or...)

Unless folks wanted to add support for element-wise and and or to the
built-in sequence types. I don't think anyone has proposed that.

Your point that the problem is mostly that the old code will still be using
>> the ``&`` operator, which could confuse people is true.
>>
>
well, yes - but code using & would continue to work the same way -- and
anyone confused would, in fact, have been mis-interpreting what & meant
already :-)

As for element-wise everything -- THAT discussion has happened multiple
times in the past, and been rejected. Time to go dig into the archives --
not sure if there is rejected PEP for it.


-CHB




-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R            (206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115       (206) 526-6317   main reception

Chris.Barker at noaa.gov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151124/be39fc85/attachment.html>