[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
 > 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



More information about the Python-ideas mailing list