[Python-ideas] Operator as first class citizens -- like in scala -- or yet another new operator?
Stephen J. Turnbull
turnbull.stephen.fw at u.tsukuba.ac.jp
Tue Jun 4 04:11:03 EDT 2019
Yanghao Hua writes:
> On Fri, May 31, 2019 at 3:48 PM Rhodri James <rhodri at 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
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.
More information about the Python-ideas