Yanghao Hua writes:
On Fri, May 31, 2019 at 3:48 PM Rhodri James email@example.com wrote:
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.
There are very constructive discussions in terms how this could be handled and which turns out not really elegant. Your justification could be used to reject features like descriptors, decorators, meta classes,
And has been so used. The question is always "does the use case justify increasing complexity for a couple hundred maintainers and a few hundred million readers?"
As far as I can tell, here we have (a) one person strongly in favor of adding just one new operator token, who justifies it based on personal preference over style of expression for one specific DSL, and (b) a few supporting a generic facility for adding new operators.
The former (a) is obviously insufficient, considering past practice in Python. One person can probably use MacroPy or a preprocessor. If the DSL becomes popular, as with "@", first applied for matrix multiplication, it might become justification for a new operator token, but the popularity has to come before more than a tiny fraction of committers (if any) will sign on. The other possibility would be to present a complete implementation of a toy language using existing Python facilities, and then show the alternative with the new operator. Preferably at the same time showing how the preprocessor/ MacroPy strategy falls short.
The latter (b) has been discussed and rejected a number of times, on the grounds that unfamiliar symbols are harder to read than functions, and that Python is not in the DSL-producing industry. Some features are clearly more descriptive than procedural in nature (eg, comprehensions), but they are justified on the ground that they increase readability when expressing algorithms.
Please let's be constructive and be specific, this kind of conclusion without any reasoning behind it
In Python practice, the conclusion of "reject" needs no reasoning, unfortunately. Python adds new features in response to a demonstrated need that overcomes a general conservatism, a conservatism that extends far past backward compatibility to a certain amount of forward compatibility as well.
So you should take your own advice. We have seen you express your preference for a new operator numerous times, but there is no visible logic behind it. Show us the best you can do with actual working hardware description classes (say a NAND gate and the composition into a half-adder, or perhaps you need more to demonstrate the relevant difficulties -- I know little about hardware, quite a bit about how the Python enhancement process works). Then show us the syntax you want to use to express the same thing.
It's possible that people with wizard-level Python skills can find a way around the difficulties you describe with descriptors and other features that have been suggested in this thread. If not, your case for a new operator token would be much stronger (though still insufficient IMO -- fortunately for you, few committers listen to me about language features ;-).
Without such a test, or a few tens of thousands of hardware designers lobbying for a decade or so (which is what happened with the numerical community, although this time around I bet Python will be substantially more forward-leaning, say 5 years and 5000 hardware designers), it's your taste against Python's conservatism. I'll take long odds that conservatism wins.