Is support for preprocessors something to consider? #21981
Replies: 1 comment 1 reply
-
|
Thanks for taking the time to write up this idea. I love the experimentation that transpilation unlocked in the JavaScript ecosystem, but I don't think it's something that can be done by "just" writing a transpiler.
If we were to build this (assuming we have time), it would require some interest and support from upstream Python that this is a direction the ecosystem wants to go and considers worth exploring and investing in. |
Beta Was this translation helpful? Give feedback.
-
|
As I imagined, there are many things to think about regarding this; it certainly wouldn't be simple. I doubt they have any real interest in that; it's very difficult. Thank you! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
I see many proposals for new or alternative syntax features on discuss.python.org.
Some examples:
-> int, intas-> tuple[int, int]) [1] [2]or/andas||/&&[1]input |> func1 |> func2[1] [2].?[1]x[y?][1]import (x, y, z)) [1]string .= upper()[1]Many are quite interesting, but in practice some may cause ambiguities, reduced readability, or perhaps only receive the following comment:
There are many factors at play when proposing a new syntax:
Even if feasible, these processes are extremely time-consuming to be accepted, as change affects everyone. Therefore, the motivations and arguments must be well-founded in the proposal to have even a minimal chance of being accepted, and even then, nothing guarantees that it will be enough to persuade.
Perhaps the best answer to this is to use preprocessors with plug-in support, so all users can choose their own custom syntaxes (whether only locally or globally) in which they feel comfortable.
It will also serve as an experiment to measure the success and failure of adapting to new syntaxes, and if it performs well, it can be incorporated into the language.
Everyone is happy:
The choice is deliberately and explicitly made by the user and this would make the use of language more flexible and more open to new ideas and ways of use.
One of the biggest criticisms from outsiders is about Python using indentation instead of curly braces, or then
or/andinstead of&&/||, and all of this may just be a matter of taste, but in the end everyone loves the fact that Python is extremely easy, but could have a different flavor.I see that Ruff/UV's proposal has been to do what other development tools do (but in a centralized and faster way), and I thought that also supporting preprocessors would be a great differentiator for the tool.
Thank you for reading this far.
Beta Was this translation helpful? Give feedback.
All reactions