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

[Yanghao Hua]

On Tue, Jun 4, 2019 at 2:28 PM Steven D'Aprano <steve at pearwood.info> wrote:
>
> 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.)

Don't make it like a war between me alone with the rest of community,
like your last paragraph, I was hoping this could be useful for more
than just me, if that is not the case, I can happily use a
self-modified cpython and move on. The truth is, I am not the only one
interested in that ... I have a lot of friends/colleagues who had way
more experience than me in hardware design and the first react of
seeing something like signal.next = thing or signal.assign(thing) is,
can you make it like signal <= thing?

I am really a newbie here in python developer community, all I was
hoping is if someone of you might have shared a similar pain. Well the
first 80 or so responses I got is: "We do not think there is a problem
...". Well, maybe I am dump, but I should improved after using python
for 20 years, and I still doesn't like how descriptor works (I wrote a
meta class to make descriptors working the way I liked, e.g.
universally doesn't matter where you define it ...) ... special cases
that it has to be a class member, and it actually overloaded the
assignment operator, but only in certain cases (e.g. signal.descriptor
= thing, not descriptor = thing) What if we had a way to overload
"assign" *universally* everywhere? For me, conceptually, "<==" is much
easier and straight forward and difficult to get wrong than the entire
descriptor concept.

>
> > 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.

Thank you Steven! This means a lot to me, that I know we can discuss
on a solid base.

> 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.

Fully agree, and I will come up with a comprehensive paper to explain
what can "<==" and "==>" simplify, not only supporting new DSLs, but
also simplify existing things like how you design an descriptor-like
behavior.