Yanghao Hua writes: > On Fri, May 31, 2019 at 3:48 PM Rhodri James <rho...@kynesim.co.uk> 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. Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
