4 ms·

See also PEP 638 – Syntactic Macros https://peps.python.org/pep-0638/ https://peps.python.org/pep-0638/

smitty1e 4y ago
You beat me to it. One wonders if this might become a python13 feature, whenever they get around to branching the CPython repository.
- ericvsmith 4y ago
  I’m contemplating pushing for it in 3.12, but it’s probably more than a year’s worth of work to implement and shepherd the PEP through. So 3.13 is more likely. And I’m not sure it won’t get shot down anyway. It’s a big step for Python.
  - smitty1e 4y ago
    I'm still not even using Typing, but, in the feature wars, it's an obvious step in the direction of maintaining featuritis parity with c++. /snark
BiteCode_dev 4y ago
Giving people the ability to create more useless unsupported DSL in a world where people think YAML dialects in the CI was a good idea will damage Python in the long run. And I say that while I wished I could use macro several times in Python because the syntax was lacking.
- kortex 4y ago
  I'm likened to agree. As much fun as syntactic macros in python would be, and despite all the doors it would open, it would really kick up the potential complexity. Heck, folks were complaining about pattern matching and the walrus operator. I mean maybe the council will go with it, but I'm bearish. I do really like the idea of jit macros and zero-overhead decorators though.
  - BiteCode_dev 4y ago
    Zero overhead exceptions are on the way so it would be natural for decorators to be next, even if it's likely way harder to implement given that decorators can basically do anything side effecty.
    - ericvsmith 4y ago
      I don't think you're likely to see zero overhead decorators any more than "zero overhead software" in general. Take dataclasses: it adds a bunch of synthesized methods to a class, and needs to use "exec" to create them. How could that be zero overhead? To help with this, I've proposed moving knowledge of dataclasses into the Python compiler, but even I don't think it's a great idea. For example, it would leave attrs in a disadvantaged position, and I don't want to do that. Another option would be to move dataclasses before the code generator. Syntactic macros are one way to do that. Then there really would be zero overhead when loading the cached .pyc files. That's their appeal to me. Of course there are lots of other things that could be done with syntactic macros, which is both good and bad.
  - ericvsmith 4y ago
    I feel the same way. I'd love to use macros to implement dataclasses. But it does open the door for unreadable code. I'm torn on the issue: I don't want to be restricted from improving dataclasses in what would be fairly obvious ways, but I'm sure the feature would be abused. But maybe this falls under the "we're all consenting adults" guideline.
anentropic 4y ago
I for one sincerely hope this does not become a thing Python already has 'enough' metaprogramming support, the last thing we need is a sudden fad of libraries defining their own gratuitous DSLs

You beat me to it. One wonders if this might become a python13 feature, whenever they get around to branching the CPython repository.

ericvsmith 4y ago
I’m contemplating pushing for it in 3.12, but it’s probably more than a year’s worth of work to implement and shepherd the PEP through. So 3.13 is more likely. And I’m not sure it won’t get shot down anyway. It’s a big step for Python.
- smitty1e 4y ago
  I'm still not even using Typing, but, in the feature wars, it's an obvious step in the direction of maintaining featuritis parity with c++. /snark

BiteCode_dev 4y ago

Giving people the ability to create more useless unsupported DSL in a world where people think YAML dialects in the CI was a good idea will damage Python in the long run. And I say that while I wished I could use macro several times in Python because the syntax was lacking.

kortex 4y ago
I'm likened to agree. As much fun as syntactic macros in python would be, and despite all the doors it would open, it would really kick up the potential complexity. Heck, folks were complaining about pattern matching and the walrus operator. I mean maybe the council will go with it, but I'm bearish. I do really like the idea of jit macros and zero-overhead decorators though.
- BiteCode_dev 4y ago
  Zero overhead exceptions are on the way so it would be natural for decorators to be next, even if it's likely way harder to implement given that decorators can basically do anything side effecty.
  - ericvsmith 4y ago
    I don't think you're likely to see zero overhead decorators any more than "zero overhead software" in general. Take dataclasses: it adds a bunch of synthesized methods to a class, and needs to use "exec" to create them. How could that be zero overhead? To help with this, I've proposed moving knowledge of dataclasses into the Python compiler, but even I don't think it's a great idea. For example, it would leave attrs in a disadvantaged position, and I don't want to do that. Another option would be to move dataclasses before the code generator. Syntactic macros are one way to do that. Then there really would be zero overhead when loading the cached .pyc files. That's their appeal to me. Of course there are lots of other things that could be done with syntactic macros, which is both good and bad.
- ericvsmith 4y ago
  I feel the same way. I'd love to use macros to implement dataclasses. But it does open the door for unreadable code. I'm torn on the issue: I don't want to be restricted from improving dataclasses in what would be fairly obvious ways, but I'm sure the feature would be abused. But maybe this falls under the "we're all consenting adults" guideline.

anentropic 4y ago

I for one sincerely hope this does not become a thing Python already has 'enough' metaprogramming support, the last thing we need is a sudden fad of libraries defining their own gratuitous DSLs