Hi Pablo,
On 15/09/2020 10:34 pm, Pablo Galindo Salgado wrote:
Thanks for the proposal Mark!
I wanted to make some comments regarding converting AST nodes to
PyObjects internally. I see some challenges here:
* Not using an arena allocator for the nodes can introduce more
challenges than simplifications. The first is that deleting a deep tree
currently is just freeing the arena block, while if the nodes were
PyObjects it will involve recursive destruction. That could potentially
segfault so we would need to use some custom trashcan mechanism of
special deleters. All of this will certainly not simplify the code (at
least the parser code) and will impact performance (although just in the
parser/compiler phase).
Don't we need to do all of this in the _ast module, already?
We already have an AST composed of Python objects.
* We would need to (potentially) reimplement the AST sequences into
proper owning-containers. That will involve changing a considerable
amount of code and some slowdown due to having to use C-API calls.
I agree that the sequences would need additional code for them to be
Python objects.
They would be more expensive to create, but I don't the additional
cost being prohibitive.
* The proposal seems to imply that the AST will be a fully public and
stable API. This has some danger as any internal optimization regarding
AST can be braking changes to macro users. This will raise any problems
that now linter and static analyst tools could have to all users (of
macros), making of even more difficult to change it.
This is a good point.
I am going to change macros to take a testlist instead of an arglist.
Historically, function arguments have been an unstable part of the API.
Since the AST node for testlist is just a list of ast.expr, it should be
stable.
That way at least the top level of the AST will be stable.
Cheers,
Mark.
Regards from sunny London,
Pablo Galindo
On Tue, 15 Sep 2020, 20:28 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/
_______________________________________________
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/DWDTBJQ6YANNPHRFIOEU4NZOPP4SVR3M/
Code of Conduct: http://python.org/psf/codeofconduct/
