5 ms·

PEP 638 – Syntactic Macros

19 points by skeledrew 11mo ago

pansa2 11mo ago
> Python is now sufficiently powerful and complex, that many proposed additions are a net loss for the language due to the additional complexity. […] Python was once described as “Python Fits Your Brain”, but that becomes less and less true as more and more features are added. Looks like this was written in 2020, but IMO Python crossed the “fits in your brain” (or at least my brain!) threshold years earlier. Nowadays, are there any popular languages that could be described that way? Maybe Go? Or Lua?
- vintagedave 11mo ago
  Pascal, maybe. It's straightforward, capable, easy to read. You see people popping up here on HN periodically with these super light-weight, fast apps written in Delphi or Free Pascal (or Oxygene, the one I've been using lately.)
bjoli 11mo ago
So they managed to make up a variable "hygiene" system that is even less useful than gensym from common lisp...
- eigenspace 11mo ago
  Yeah, that was rather puzzling. Hopefully if this proposal garners any interest, some people with actual experience with dealing with macro hygiene issues can help fix that.
eigenspace 11mo ago
IMO Python really needs this. Working in a language without syntatic macros is such a downgrade, and there's been a number of syntax features added to the language over the years that IMO should have just been macros. > The f-string `f"..."` could be implemented as macro as `f!("...")`. Not quite as nice to read, but would still be useful for experimenting with. In julia, we have a rule where a macro whose name ends with `_str` is usable as a "string macro" and it receives the input string in its raw form, and then any string macro is usable by just prefixing the name at the beginning of the string. An example is that our regex string literal implementation is literally just macro r_str(s) Regex(s) end which allows for easy compile-time regex generation. With that you can simply write e.g. `r"^[ \t]+|[ \t]+$"` which is the same as `@r_str("^[ \t]+|[ \t]+$")`, e.g. julia> match(r"^[ \t]+|[ \t]+$", " hi") RegexMatch(" ") So using this rule, Python's f-strings could just be re-implemented as a string macro. https://docs.julialang.org/en/v1/manual/metaprogramming/#meta-non-standard-string-literals https://docs.julialang.org/en/v1/manual/metaprogramming/#met...
- peterlada 11mo ago
  No
  - eigenspace 11mo ago
    Yes.
    - deleted 11mo ago
      [deleted]
- skeledrew 11mo ago
  This is possible in 3.14, which includes "PEP 750 – Template Strings", a generalization of f-strings. Perhaps macros is the next step of evolution.
  - eigenspace 11mo ago
    Having a real macro system would be a replacement for that PEP
    - skeledrew 11mo ago
      Well they should coexist, as all string formatting syntaxes have over the years. And though I think macros would be nice to have, there's a valid concern raised in the discussion: readability. Having macros opens the door to extremely unpythonic code bases, which could be very hard for anyone outside of the primary audience to understand, let alone meaningfully modify or contribute to. And one of the things that keeps me hooked to Python is that if I install a package and it has some issue or doesn't do something I'd like, it's almost trivial for me to find the relevant section in the installed code, edit it and have the desired behavior on next invocation.
7bit 11mo ago
Can someone explain this in simpler terms? I think I'm quite proficient in Python for a sysadmin, but I don't understand a single statement in the PEP.
- eigenspace 11mo ago
  A macro is a function that takes in parsed code and returns transformed code. The nice thing about macros is that they run during the parsing of the code, so they have no runtime cost associated with them. Basically, you can think of it as a (limited) way for users or packages to add new keywords to a language without having to change the whole language implementation for everyone. Many recent new keywords that were added to Python could have been implemented as macros, which means that they could have just lived in packages rather than needing to be upstreamed into the base language implementation from day 1.
xigoi 11mo ago
(2020)
- gabrielsroka 11mo ago
  Take 16 https://hn.algolia.com/?query=PEP%20638%20%E2%80%93%20Syntactic%20Macros&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=PEP%20638%20%E2%80%93%20Syntac...
lihaoyi 11mo ago
I actually implemented something of this sorts back in college: MacroPy https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy
clickety_clack 11mo ago
I don’t know the pros or cons of macros as I haven’t used them in any language, but the language seems to be picking up more hacks recently.

19 points by skeledrew 11mo ago

pansa2 11mo ago

> Python is now sufficiently powerful and complex, that many proposed additions are a net loss for the language due to the additional complexity. […] Python was once described as “Python Fits Your Brain”, but that becomes less and less true as more and more features are added. Looks like this was written in 2020, but IMO Python crossed the “fits in your brain” (or at least my brain!) threshold years earlier. Nowadays, are there any popular languages that could be described that way? Maybe Go? Or Lua?

vintagedave 11mo ago
Pascal, maybe. It's straightforward, capable, easy to read. You see people popping up here on HN periodically with these super light-weight, fast apps written in Delphi or Free Pascal (or Oxygene, the one I've been using lately.)

bjoli 11mo ago

So they managed to make up a variable "hygiene" system that is even less useful than gensym from common lisp...

eigenspace 11mo ago
Yeah, that was rather puzzling. Hopefully if this proposal garners any interest, some people with actual experience with dealing with macro hygiene issues can help fix that.

eigenspace 11mo ago

IMO Python really needs this. Working in a language without syntatic macros is such a downgrade, and there's been a number of syntax features added to the language over the years that IMO should have just been macros. > The f-string `f"..."` could be implemented as macro as `f!("...")`. Not quite as nice to read, but would still be useful for experimenting with. In julia, we have a rule where a macro whose name ends with `_str` is usable as a "string macro" and it receives the input string in its raw form, and then any string macro is usable by just prefixing the name at the beginning of the string. An example is that our regex string literal implementation is literally just macro r_str(s) Regex(s) end which allows for easy compile-time regex generation. With that you can simply write e.g. `r"^[ \t]+|[ \t]+$"` which is the same as `@r_str("^[ \t]+|[ \t]+$")`, e.g. julia> match(r"^[ \t]+|[ \t]+$", " hi") RegexMatch(" ") So using this rule, Python's f-strings could just be re-implemented as a string macro. https://docs.julialang.org/en/v1/manual/metaprogramming/#meta-non-standard-string-literals https://docs.julialang.org/en/v1/manual/metaprogramming/#met...

peterlada 11mo ago
No
- eigenspace 11mo ago
  Yes.
  - deleted 11mo ago
    [deleted]
skeledrew 11mo ago
This is possible in 3.14, which includes "PEP 750 – Template Strings", a generalization of f-strings. Perhaps macros is the next step of evolution.
- eigenspace 11mo ago
  Having a real macro system would be a replacement for that PEP
  - skeledrew 11mo ago
    Well they should coexist, as all string formatting syntaxes have over the years. And though I think macros would be nice to have, there's a valid concern raised in the discussion: readability. Having macros opens the door to extremely unpythonic code bases, which could be very hard for anyone outside of the primary audience to understand, let alone meaningfully modify or contribute to. And one of the things that keeps me hooked to Python is that if I install a package and it has some issue or doesn't do something I'd like, it's almost trivial for me to find the relevant section in the installed code, edit it and have the desired behavior on next invocation.

7bit 11mo ago

Can someone explain this in simpler terms? I think I'm quite proficient in Python for a sysadmin, but I don't understand a single statement in the PEP.

eigenspace 11mo ago
A macro is a function that takes in parsed code and returns transformed code. The nice thing about macros is that they run during the parsing of the code, so they have no runtime cost associated with them. Basically, you can think of it as a (limited) way for users or packages to add new keywords to a language without having to change the whole language implementation for everyone. Many recent new keywords that were added to Python could have been implemented as macros, which means that they could have just lived in packages rather than needing to be upstreamed into the base language implementation from day 1.

xigoi 11mo ago

(2020)

gabrielsroka 11mo ago
Take 16 https://hn.algolia.com/?query=PEP%20638%20%E2%80%93%20Syntactic%20Macros&type=story&dateRange=all&sort=byDate&storyText=false&prefix&page=0 https://hn.algolia.com/?query=PEP%20638%20%E2%80%93%20Syntac...

lihaoyi 11mo ago

I actually implemented something of this sorts back in college: MacroPy https://github.com/lihaoyi/macropy https://github.com/lihaoyi/macropy

clickety_clack 11mo ago

I don’t know the pros or cons of macros as I haven’t used them in any language, but the language seems to be picking up more hacks recently.