[Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?

[Steven D'Aprano]

On Fri, May 31, 2019 at 02:48:24PM +0100, Rhodri James wrote:
> On 29/05/2019 08:31, Yanghao Hua wrote:

> >Python does not need to know this ... just hand it over to end user
> >who knows how to implement such a thing. Python need to provide the
> >mechanism.
> 
> It really doesn't.  If the end user is going to implement the logic of 
> this anyway, implementing signal linkage as a method call or class all 
> of its own is not a significant extra burden.

That's not really fair: syntax matters, and for people working in a 
domain where certain syntax is expected, asking them to use something 
different is a significant cognitive burden. We don't ask people doing 
arithmetic to write code like this:

x.mul(y.sub(1))  # a * (y - 1)

There have been at least two times that Python has added syntax to the 
language to allow a third-party library to write more-idiomatic code in 
their domain. Both extended slicing seq[a:b:c] and the matrix- 
multiplication operator were added for numpy.

So *in principle* we certainly could add a new arrow operator for 
Yanghao Hua so his libraries and code will be more expressive and 
idiomatic in his domain.

But *in practice*, the hard truth is this:

- Yanghao Hua is one developer interested in HDL in Python;

- numpy was, and still is, one of the most important "killer apps"
  responsible for Python's success.

Adding syntax for the benefit of numpy helps millions of users; adding 
syntax for HDL-like helps... how many people? Twenty? A hundred?

Millions of users will have to learn the syntax. Unless they get some 
benefit, why consider this?

(But having said that... I reckon that if we had left and right arrow 
operators, <== and ==>, I have some DSLs where they would work for me 
too. Maybe.)


> I'm pretty much done with this conversation too.  You have repeatedly 
> been asked what problem you are trying to solve and repeatedly respond 
> by restating your solution, which appears to be to impose HDL sematics 
> onto a non-HDL language.  That's never going to be a good idea.

That's totally unfair to Yanghao Hua on two levels.

(1) He has never asked for the interpreter to support the semantics he 
wants. He's not asking for Python to understand and implement HDL 
semantics in the language: he can do that himself, in the class.

(2) He has explained the problem he is trying to solve: he wants to 
write a DSL using syntax which doesn't look like crap from the 
perspective of people in that domain.

He just wants an operator that looks kinda like assignment that calls a 
dunder. He can't use assignment because the semantics are baked into the 
language (and there's no chance of that changing). He can't use existing 
operators because they're already in use.

This is not an unreasonable request. Python has bowed to similar 
requests at least twice before, and honestly, it's not like a <== 
operator would be weirder than other operators in use in mainstream 
languages. We're not talking APL or J here.

On the other hand... its not clear that, as small as this request is, 
the language would be better. There's lots of other domains where Python 
syntax is sub-optimal: 

- We don't have good syntax for writing XML, or calling SQL. We just
  have to use strings.

- No nice syntax for writing Prolog-style deductive code;

- or concatenative DSLs;

- or natural language DSLs like Hypertalk or Inform.


Python can't be all things to all people. 



-- 
Steven