Yanghao Hua writes:
On Tue, Jun 4, 2019 at 10:11 AM Stephen J. Turnbull
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.
Good! It will be interesting to see if any of the wizards are willing to weigh in, and what they'll come up with.
Looking forward to it!