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

[Nick Coghlan]

On 27 November 2015 at 06:54, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Andrew Barnert via Python-ideas wrote:
>>
>> But "elementwise" isn't what people doing symbolic computation or most
>> other
>> uses of DSL/expression-tree libraries are doing.
>
> Right. I think just describing them as "overloadable versions
> of the boolean operators" would be best. What they mean is
> up to the types concerned, just as with all the oher operators.

Except that *isn't* what we do with the other operators. "&" is the
bitwise and operator, for example - that's why the special method is
called "__and__". The fact you can use it for an elementwise bitwise
and operation on NumPy arrays, or for set intersection, isn't part of
the core design. If there isn't *at least one* specific motivating use
case, then "it might be useful for something" isn't a good reason to
add new syntax.

However, looking again at PEP 335, I'm not sure I see any reason it
needs to noticeably slower in the standard case than the status quo
(I'm not saying it would be *easy* to retain the speed, but the
complexity would be in the eval loop implementation and the code
generation process, not user code). We also have the richer benchmark
suite these days to actually quantify the impact of checking for the
new __and1__/__or1__ slots before falling back to __bool__, and
tracing JIT's would still be able to generate appropriate code for the
fast path at runtime.

So perhaps it might be worth dusting off that original idea and seeing
what the impact is on the performance benchmarks?

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia