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.

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.

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.

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.