Hi David,
On 15/09/2020 9:20 pm, David Mertz wrote:
Three-ish questions:
1. What could this do that Macropy does not already do? (yes, I know
"run as top-level script", but that's uninspiring for me).
Macros in MacroPy don't look like macros, they look
like normal Python code.
The proposed macros have distinct syntax, making it obvious at a glance
that they are macros. Since the macro name is a distinct token it makes
it obvious, especially once editors start highlighting them differently.
The proposed macros support additional syntactic forms.
The additional stmt_expr AST node make it possible to support complex
flow control like finally blocks, which MacroPy cannot do.
The import hooks that MacroPy uses have no means to support macro
versioning, resulting in either stale pyc files or excessive compilation.
I'm not sure which.
2. Do you have any evidence Numba developers would actually want this?!
(as claimed in draft FAQ). I know a lot of them, and teach Numba
sometimes, although have not directly contributed. I do not believe
they would prefer the AST to the bytecode for the analysis.
When writing a compiler you want the AST. It doesn't really matter what
the compiler is.
I'll change the example, so that I'm not attributing things to the numba
developers without their consent.
3. I guess not really a question, but I just can't see a language
feature like this as fully "opt-in". Any feature that is added is going
to occur in code I wind up having to maintain. That's already a pain
point with e.g. metaclasses/decorators, monkey patching, and other
constructs, where code often doesn't mean what it *looks like* it would
mean.
Whether a macro does what it looks like it does is largely down to
naming and design. The same could be said of library code in general.
... macros, even if hygienic, seem to make that need to learn a new DSL
or language for every code base much worse than those other constructs.
Looking at code with entirely novel flow control constructs adds a lot
of cognitive burden. Not least because there are likely to be a hundred
different implementations that make "case" or "do until" do very subtly
different things in each one.
On Tue, Sep 15, 2020 at 9:27 AM Mark Shannon <m...@hotpy.org
<mailto:m...@hotpy.org>> wrote:
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
<mailto:python-dev@python.org>
To unsubscribe send an email to python-dev-le...@python.org
<mailto: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/
--
The dead increasingly dominate and strangle both the living and the
not-yet born. Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
_______________________________________________
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/XGVYQNA7UIIKDWHUSKQFGFK2UZKUQT73/
Code of Conduct: http://python.org/psf/codeofconduct/
