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.
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.
> 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?
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.)
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.
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.
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.
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
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. 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/#met...
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.
Having a real macro system would be a replacement for that PEP
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.
No
Yes.
> 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?
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.)
So they managed to make up a variable "hygiene" system that is even less useful than gensym from common lisp...
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.
I actually implemented something of this sorts back in college: MacroPy https://github.com/lihaoyi/macropy
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.
(2020)
Take 16
https://hn.algolia.com/?query=PEP%20638%20%E2%80%93%20Syntac...
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.
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.