On Tue, Jun 4, 2019 at 2:28 PM Steven D'Aprano <st...@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. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/