[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 13:32:23 EDT 2019


Yanghao Hua writes:
 > On Tue, Jun 4, 2019 at 10:11 AM Stephen J. Turnbull
 > <turnbull.stephen.fw at u.tsukuba.ac.jp> wrote:

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

I'm sorry, but you seem to misunderstand what I mean by "complex" in
this context.  "Complex" refers to the *entire* Python language, and
what happens to the difficulty of maintaining and learning the
language if *all* proposed features of similar (or better)
benefit/cost tradeoff are added.

Some developers argue that our own bar is clearly too high.  I tend to
disagree, mostly on the grounds that many core developers frequently
confess to being overburdened by the current pace of change and needs
for maintenance.

 > hundred million readers. I can only guess you mean python
 > developers here?

I mean anybody who reads Python code.  Mostly developers who program
in Python, of course.  But it also includes lots of people who aren't
Python developers, and may not be experienced developers at all, but
just want to understand if some code fits their needs so they can
cargo-cult it, or just use it as a plug-in.

 > Just like @=, <== is not enforced on anyone, but can be used by
 > anyone who wants to.

But they *are* enforced.  They are forced on anyone who wants to read
code using them.  In general, Python prioritizes readers over writers
of code.  You can, and we do, argue about whether that tradeoff is
made appropriately in any given case, but I doubt you'll find anyone
to disagree that that is an important principle.  (A few disagree with
the importance it's given, of course, but they'll admit that it is
frequently mentioned in these discussions.)

 > I am glad that this question comes, which means at least the python
 > community is no longer denying there is a problem

That's not fair.  I don't recall anyone denying you have a problem
worth solving.  I did see objections to your proposed solution.  I
also saw strong doubt that you've exhausted the possibilities of the
existing Python language.  Essentially all proposals for new syntax
(including new operators) get the same questioning.

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

Good!  It will be interesting to see if any of the wizards are willing
to weigh in, and what they'll come up with.

 > Stay tuned.

Looking forward to it!

Steve


More information about the Python-ideas mailing list