As someone who has never done meta-programming before, this looks very interesting. Considering how powerful it seems, will this make metaclasses redundant?
I don’t think so. This is intended for some specific use case as explained in the examples:
Where I see macros having real value is in specific domains, not in general purpose language features.
And unlike metaclasses, syntactic macros come with a slight performance downside:
For code that does use macros and has already been compiled to bytecode, there will be some slight overhead to check that the version of macros used to compile the code match the imported macro processors. For code that has not been compiled, or compiled with different versions of the macro processors, then there would be the usual overhead of bytecode compilation, plus any additional overhead of macro processing.
I’m glad to see that Python team is continuously taking into consideration of other domains like data science that rely heavily on Python, macros will alleviate some of these domain challenges without making changes to the language itself. As someone currently studying data science, I often stumble upon APIs that are non-Pythonic in many third-party DS libraries, and the new macros might introduce more non-Pythonic practice and less readable code, as mentioned by many critics in this Hacker News thread.
If this proposal gets accepted, I’d like to ask to the people behind this, please add an explicit and fairly strict guideline to the documentation page on when and when not to use macros, much like the PEP 8 style guide, or the zen of Python. So by following the macro guide itself can still be Pythonic.
This post was flagged by the community and is temporarily hidden.