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

[David Mertz]

I find the need to use np.logical_or quite often in NumPy.  I'm sure the
NumPy community would much prefer to be able to write:

    new = arr[arr<10 or arr>100]

Instead of the current:

    new = arr[np.logical_or(arr<10, arr>100)]

Likewise for np.logical_and().


On Mon, Nov 30, 2015 at 10:23 AM, Guido van Rossum <guido at python.org> wrote:

> Well, there is still the issue of whether numpy would adopt PEP 335 even
> if it was implemented. I'm still waiting for a response to my message
> questioning how common `bool_value and/or numpy_array` really is.
>
> Also, there may still be a significant difference between PEP 335 and your
> proposal -- IIUC in your proposal if the value of the first operand
> requires the second operand to be evaluated (e.g. `True or y`) then in your
> proposal if y defined the 'r' special method it will be used; I don't think
> PEP 335 does that. I like your version better.
>
> On Mon, Nov 30, 2015 at 10:08 AM, Henry Schreiner <
> henryschreineriii at gmail.com> wrote:
>
>> I didn't realize the similarity of the proposals. I do think that testing
>> for existence is better than running a method (that might not exist), at
>> least from a high level perspective.
>>
>> So PEP 335 might be dusted off again and run through benchmarks? There
>> seems to be at least a test implementation for Python 2.3, are there
>> benchmarks documented somewhere? It sound like the version that adds new
>> byte codes instead of an additional byte code per op was never included.
>>
>> I do like the cleanliness of not adding extra operators with nearly
>> identical meanings.
>>
>> On Monday, November 30, 2015 at 11:24:12 AM UTC-6, Guido van Rossum wrote:
>>>
>>> On Mon, Nov 30, 2015 at 8:22 AM, Henry Schreiner <henrysch... at gmail.com>
>>> wrote:
>>>
>>>> Sorry, the order was incorrect in that last message. It should be:
>>>>
>>>> When x and y is written, if x has __booland__, then x.__booland__(y) is
>>>> returned. If not, then return x if x==False else if x==True, then if y
>>>>  has y.__rbooland__(x), that is returned. If not, then return y
>>>>
>>>
>>> This proposal isn't significantly different from PEP 335. In PEP 335,
>>> first you ask the left operand whether to overload 'and' or not (by calling
>>> its __and1__); if it says yes, you evaluate the second arg and ask the
>>> first to evaluate it. In your proposal, the first question is answered by
>>> inspecting whether x defines __booland__. I don't think this makes much
>>> practical difference. The second part of your proposal is just a renaming
>>> of __and2__/__rand2__ to __booland__/__rbooland__. I'm not sure I like this
>>> much; the return type of these methods is almost never going to be an
>>> actual bool, so the 'bool' in the name is somewhat misleading. (The names
>>> chosen in PEP 335 are intentionally free of semantic hints, since the
>>> intuition of someone who encounters these for the first time isn't likely
>>> to be useful.)
>>>
>>> --
>>> --Guido van Rossum (python.org/~guido)
>>>
>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
Keeping medicines from the bloodstreams of the sick; food
from the bellies of the hungry; books from the hands of the
uneducated; technology from the underdeveloped; and putting
advocates of freedom in prisons.  Intellectual property is
to the 21st century what the slave trade was to the 16th.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20151130/5495b077/attachment-0001.html>