On Tue, Jun 4, 2019 at 2:28 PM Steven D'Aprano email@example.com 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.