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. Some examples: * Remove debug code like assertions and logs to make the code faster to run it for production. * Tail-call Optimization * 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/ -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ 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/QPVBRXDRUCOS5TJ7JAX4D5NW3MITYWEL/ Code of Conduct: http://python.org/psf/codeofconduct/
