[Python-Dev] Re: Hygenic macros PEP.

On Wed, Sep 16, 2020 at 3:53 PM Mark Shannon wrote: > [...] > > maybe!(a.b) > > which would translate to: > > $tmp = a; None if $tmp is None else ($tmp.b) > > This reminds me very much of PL/1's "compile-time procedures," which forty years ago were pretty much like PL/1

[Python-Dev] Re: Python 4 FAQ

On 9/15/20 8:54 PM, Steven D'Aprano wrote: > There's still a lot of community angst over the possibility that > some hypothetical Python 4 will be like the 2/3 transition. Some people > even imagine that the version after 3.9 could be that transition. > > I know we're not responsible for the

[Python-Dev] Re: Hygenic macros PEP.

Hi Guido, On 16/09/2020 5:54 am, Guido van Rossum wrote: On Tue, Sep 15, 2020 at 7:31 PM Benjamin Peterson > wrote: On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote: > Maybe the PEP should propose an AST of its own, which would initially > be a third

[Python-Dev] Re: Hygenic macros PEP.

Hi Benjamin, I don't like the idea of just passing a stream of tokens to the macro processor, for three reasons. 1. It makes life unnecessarily difficult for macro implementers by forcing them to parse the stream of tokens. Macros may contain difficult to parse constructs, and other macros.

[Python-Dev] Re: Hygenic macros PEP.

On 16.09.2020 16:33, Benjamin Peterson wrote: Is there any proposal that would let you add new tokens? Not a proposal, but drafted a project a while back. By patching tokenizer and the parser at runtime (generated from lib2to3.pgen), allowed to introduce different tokens / rules, and

[Python-Dev] Re: Hygenic macros PEP.

On Tue, Sep 15, 2020, at 23:54, Guido van Rossum wrote: > On Tue, Sep 15, 2020 at 7:31 PM Benjamin Peterson wrote: > > On Tue, Sep 15, 2020, at 20:10, Greg Ewing wrote: > > > Maybe the PEP should propose an AST of its own, which would initially > > > be a third thing separate from either of

[Python-Dev] Re: Hygenic macros PEP.

September 16, 2020 12:24 AM, "Guido van Rossum" mailto:gu...@python.org?to=%22Guido%20van%20Rossum%22%20)> wrote: This may actually address the worry that was expressed that libraries will become too dependent on macros, by making it painful to maintain a macro processor across many versions.

[Python-Dev] Re: Hygenic macros PEP.

> Would it complicate the parser much to allocate memory using a different allocator? It's just a function call, presumably. Is not the allocator per-se, is the fact that with the arena we can free *all the memory* in one single call, instead of having to implement custom free functions for the

[Python-Dev] Re: Hygenic macros PEP.

On 16/09/2020 12:22 pm, Pablo Galindo Salgado wrote: > Don't we need to do all of this in the _ast module, already? > We already have an AST composed of Python objects We have AST of Python objects, but the python versions are not used internally, especially in the parser, where

[Python-Dev] Re: Hygenic macros PEP.

Hi Matthias, On 15/09/2020 11:25 pm, Matthias Bussonnier wrote: Mark, Thanks you this is an interesting proposal. I can see how many of the "magics" provided by IPython/Jupyter could also be replaced by some of those macros. A couple of questions – which I understand could be delegated to

[Python-Dev] Re: Hygenic macros PEP.

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

[Python-Dev] Re: Hygenic macros PEP.

> > Don't we need to do all of this in the _ast module, already? > > We already have an AST composed of Python objects We have AST of Python objects, but the python versions are not used internally, especially in the parser, where they are created. The parser and the compiler currently use

[Python-Dev] Re: Hygenic macros PEP.

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

[Python-Dev] Re: Hygenic macros PEP.

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

[Python-Dev] Re: Hygenic macros PEP.

Hi Daniel, On 15/09/2020 9:02 pm, Daniel Butler wrote: > Users would be encouraged to try it but > NOT to publish code using it. Thinking out loud, macros could be enabled with a command line flag. Advanced users would know how to use it but others would not. If the macro flag

[Python-Dev] Re: Hygenic macros PEP.

> > > * 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