[Python-ideas] Revisiting dedicated overloadable boolean operators

[Jonathan Fine]

Hi Todd

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

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 would benefit many existing users and projects now, without
having to wait for the introduction of a new version of Python, and
their project adopting that version.

It may help to build on PEP 465 -- A dedicated infix operator for
matrix multiplication
https://www.python.org/dev/peps/pep-0465/

This addition allows you (from the PEP) to write
>>> S = (H @ beta - r).T @ inv(H @ V @ H.T) @ (H @ beta - r)

You my want to extend the syntax and semantics so that
>>> S = (H @beta - r).T @ inv(H @ V @ H.T) @ (H @beta - r)
invokes double-under methods, whose name might be something like
__at_beta__

I'm impressed by
> https://en.wikipedia.org/wiki/Fluent_interface
> https://martinfowler.com/bliki/FluentInterface.html
and encourage work on tools for creating such in Python.

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.

However, as Steve Dower pointed out last month, we can use lamda for
this purpose. I think it's easy to define a function OR such that the
following
> EXP_1 or EXP_2
>> OR(lambda: EXP_1, lambda:EXP_2)
do pretty the same thing (except refactoring the expressions into the lambdas).

In fact, I think OR has to be
>>> def OR(fn_1, fn_2):
...     return fn_1() or fn_2()

I hope this help you solve the underlying problems, and have a better
time with Python.

-- 
Jonathan