Correct me if I am wrong: Yanghao would like an elegant way to build
graphs. Simply using << to declare the connections in the graph [1] is
not an option because << is already needed for legitimate left-shift
operation. The problem is not assignment; rather, Yanghao's HDL
requires more operators than Python has in total (or at least the
remaining operators look terrible).
Here is a half baked idea:
Instead of solving the problem of operator-needed-for-use-case-X, can we
solve the bigger problem of adding user-defined operators?
"User-defined operators" are a limited set of operators, with no
preconceived definition, and can be defined by writing the appropriate
dunder method. User-defined operators match /[!@$%^-+=&*:<>?/|]{2,4}/
and necessarily exclude all the existing python-defined operator
combinations. Maybe 50K operators is easier to add to Python than a few
pre-defined operators?
Example:
> class A:
> def assign(self, other):
> # whatever this means
To add a user defined operator to a class, you add it as a method,
exactly the name of the operator:
> setattr(A, "<==", A.assign)
I admit this is a bit ugly, but some decorator can make this nicer:
> class A:
> @operator("<==")
> def assign(self, other):
> # whatever this means
Maybe the biggest problem would be with linting; not being able to
distinguish between a typo and a user-defined operator until runtime,
when no implementation is found.
A ++= B # is this typo?
Abusive use of operators will likely happen; but the codebases that do
will not be popular because of the learning curve. Instead, experiments
will be done, some will succeed, and the best operators for each domain
will become popular. Then the python devs can pick the winners to
include in the core library, if any.
[1] Here is toy example that will build a graph using << and >>:
https://github.com/klahnakoski/graph-builder/blob/master/graph_builder.py
On 2019-06-04 08:28, Steven D'Aprano 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.)
>
>
>> 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.
>
>
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/DORAD4KGDNAGEXV3GDM266FSA23W3VLW/
Code of Conduct: http://python.org/psf/codeofconduct/
