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

[Andrew Barnert]

On Nov 26, 2015, at 18:11, Nick Coghlan <ncoghlan at gmail.com> wrote:
> 
>> 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.

Sure. But the sqlanywhere case was the very first motivating use the OP mentioned, before NumPy, not something that may come up in the future that we haven't imagined yet.

Also, the distinguishing thing about this new magic method vs. the existing __and__ isn't that it's elementwise, but that it's boolean/logical rather than bitwise/arithmetic, even for NumPy users. So, calling it "elementwise and", or giving it a name that implies elementwise, will confuse anyone who hasn't read this whole thread.

And finally, NumPy is one of the uses that doesn't require short circuiting, and the same is almost certainly true for other elementwise uses, and yet we seem to all be agreed that the new overload has to be short-circuitable.

> 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
> _______________________________________________
> 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/