[Python-ideas] Revisiting dedicated overloadable boolean operators

[Todd]

On Fri, Aug 3, 2018 at 2:26 PM, Jonathan Fine <jfine2358 at gmail.com> wrote:

> Hi Todd
>
> Thank you for your contribution! I've got a couple of comments. The
> experts, I hope, will have more to say.
>
>
Thanks for your reply, Jonathan.



> You wrote:
>
> > As to why this is useful, the overall problem is that the current logical
> > operators, like and, or, and not, cannot be overloaded, which means
> projects
> > like numpy and SQLAlchemy instead have to (ab)use bitwise operator
>
> > There was a proposal to allow overloading boolean operators in Pep-335
> [2],
> > but that PEP was rejected for a variety of very good reasons.
>
> The key thing is, I think, the wish for a domain specific language. I
> find this to be a wholesome wish. But I'd rather create a broad
> solution, than something that works just for special cases. And if at
> all possible, implement domain specific languages without extending
> the syntax and semantics of the language.
>

This proposal isn't domain-specific.  I think the fact that it would
benefit projects as diverse as numpy and SQLAlchemy (as well as others such
as sympy) demonstrates that.

Boolean operators like the sort I am discussing have been a standard part
of programming languages since forever.  In fact, they are the basic
operations on which modern microprocessors are built.

The fact that Python, strictly speaking, doesn't have them is extremely
unusual for a programming language.  In many cases they aren't necessary in
Python since Python's logical operators do the job well enough, but there
are a set of highly diverse and highly prominent cases where those logical
operators won't work.  There are workarounds, but they are less than
optimal for the reasons I describe, and the previous discussion I linked to
goes into much more detail why these new operators are important.

There is the problem of short-circuiting evaluation, as in the 'and'
> and 'or' operators (and elsewhere in Python). This has to be a syntax
> and semantics feature. It can't be controlled by the objects.
>

Yes, sorry, I left that out.  The consensus from the previous discussion is
that this wouldn't be short-circuiting.  I can imagine ways to support
short-circuiting as well (such as a second set of dunder methods with one
set overriding the other), but it isn't really relevant to my proposal.
This proposal is assuming the semantics from the previous discussion.  All
I am trying to address here is how the operators would be spelled.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20180803/3e126146/attachment.html>