Hi Victor,
On 15/09/2020 10:55 pm, Victor Stinner wrote:
Hi Mark,
In 2016, I wrote PEP 511 "API for code transformers" which proposed a
different implementation but also used "preprocessor" use case in the
rationale:
"""
A preprocessor can be easily implemented with an AST transformer. A
preprocessor has various and different usages.
PEP 511 seems to be entirely focused on performance.
My PEP is about semantics.
Some examples:
* Remove debug code like assertions and logs to make the code faster
to run it for production.
* Tail-call OptimizationTail-call recursion only, surely?
Tail-call elimination in general would need interpreter support.
* Add profiling code
* Lazy evaluation: see lazy_python (bytecode transformer) and lazy
macro of MacroPy (AST transformer)
* Change dictionary literals into collection.OrderedDict instances
* Declare constants: see @asconstants of codetransformer
* Domain Specific Language (DSL) like SQL queries. The Python language
itself doesn't need to be modified. Previous attempts to implement DSL
for SQL like PEP 335 - Overloadable Boolean Operators was rejected.
* Pattern Matching of functional languages
* String Interpolation, but PEP 498 -- Literal String Interpolation
was merged into Python 3.6.
MacroPy has a long list of examples and use cases.
This PEP does not add any new code transformer. Using a code
transformer will require an external module and to register it
manually.
"""
https://www.python.org/dev/peps/pep-0511/#usage-2-preprocessor
I rejected my PEP, extract of the rejection notice:
"""
This PEP was seen as blessing new Python-like programming languages
which are close but incompatible with the regular Python language. It
was decided to not promote syntaxes incompatible with Python.
This PEP was also seen as a nice tool to experiment new Python
features, but it is already possible to experiment them without the
PEP, only with importlib hooks. If a feature becomes useful, it should
be directly part of Python, instead of depending on an third party
Python module.
"""
https://www.python.org/dev/peps/pep-0511/#rejection-notice
Victor
Le mar. 15 sept. 2020 à 21:27, Mark Shannon <m...@hotpy.org> a écrit :
Hi all,
I'd like to propose a new PEP for hygienic macros.
I'm attempting to reduce the controversy and pain of adding new syntax
to Python,
... by adding new syntax.
That might sound silly, but I hope to persuade that it isn't.
Adding a new feature to the language is always controversial.
Before a new module or functionality is added to the standard library,
it must usually prove itself as a package on PyPI.
(Not always the same package, the value of dataclasses was demonstrated
by "attrs".)
However, this isn't currently possible with new language features.
Any new language feature has pros and cons.
It adds expressive power for some (usually experienced) users,
but potentially confuses and inconveniences other users (especially
beginners).
However, it is very hard, if not impossible, to determine whether adding
new syntax will be be beneficial or harmful before the syntax is added.
Is there a way to add new syntax in a way that allows it be battle
tested before adding to the released version of the language?
Yes there is, Macros.
I'm not talking about C-style macros which do textual substitution, but
"hygienic" macros that rewrite the AST during compilation.
Macros allow domain specific new syntactic features, without bloating
the language or confusing newcomers.
In general, I would except macros to be used within libraries, so that
those libraries gain the power of their custom macros without making
Python ever larger and more complex.
However, there is no reason why they cannot be made more widely
available. Should a macro become widely used and popular, then it can be
considered for adoption into the language.
The PEP:
https://github.com/markshannon/peps/blob/hygenic-macros/pep-0700.rst
Cheers,
Mark.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/7BX4S6ROKPMTTJR64UPRJ4D66C23HMHI/
Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/QLI62HJNPCZYBTHHSYHN7GVBF5UAUUK7/
Code of Conduct: http://python.org/psf/codeofconduct/
