On Tue, Jun 4, 2019 at 10:11 AM Stephen J. Turnbull <turnbull.stephen...@u.tsukuba.ac.jp> wrote: > > 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?"
That's a valid question. and let's address the items one by one. Complexity & hundreds of maintainers. It is nothing complex and it is almost a direct copy of the implementation of @= operator, all logic behind <== are the same of @=. With some refactoring @= and <== implementation might even be able to share 99% of the code, so I think it is not complex at all, and there is not much additional overhead for maintenance. hundred million readers. I can only guess you mean python developers here? Just like @=, <== is not enforced on anyone, but can be used by anyone who wants to. As it is today I can choose to give @= a complete different meaning if I chose to, other uses may chose (and most importantly, being able to) give <== the meaning they see fit when they want to preserve all number operators and matrix operators. It is merely a new possibility for end user with very limited effort. I am glad that this question comes, which means at least the python community is no longer denying there is a problem (a small one by the way), and it can be improved in terms of allowing end user to write more readable code in this specific domain. > 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. Will do. > 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. Understood. > > 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. I will come up with a complete working implementation of HDL-in-Python with <== to show the differences, how it enhances readability, and how it compares without it. > 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 ;-). I'd like to take any recommendations that can achieve the same logical integrity and readability. > 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. Thanks for the advice, I will (I was) working on it and will show you the ideas behind it. I knew it is going to be difficult and probably I have failed to use some cool features and I think a completely working system will help to demonstrate the ideas better. Stay tuned. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
