> Indeed, internally it rewrites the AST, of course. I think that's the > simplest way to implement it. But it doesn't mean the user that write > the compile-time code would have to be aware of the AST at all. > I mean, if you have a good use-case for it, then I'm ok with allowing > the compile-time code manipulating it. But I'd really prefer this not be > the main use of the compile-time execution feature.
Ah. I see where you are coming from. Wouldn't this be a ridiculous amount of work? At least if we insisted on something with a clean mental model that wouldn't just shred the user with a thousand corner cases? It would need a whole new sub-syntax in Cython with detailed semantics for all the weird things code lets people do (e.g. what if the input function f gets used like a first-class object and placed in a Python list that then gets passed to another function... at compile time...). You're basically asking for scheme's syntax-case but harder because Python/Cython are nowhere near as regular! And scheme's syntax-case is a beast (read up on phase separation if you don't believe me: https://docs.racket-lang.org/guide/phases.html). AST manipulation isn't _that_ hard (esp. with good helper libraries) and on the plus side, the basic idea is dead-simple to implement: just call some random Python function that the user points you towards. There's going to be some scaffolding but of an entirely manageable amount. I mean... if you think "there's really no major obstacle" then more power to you! I'd love to see what you come up with. But I think you're underestimating the complexity of the task. -- ________________________ Warm Regards Prakhar Goel _______________________________________________ cython-devel mailing list cython-devel@python.org https://mail.python.org/mailman/listinfo/cython-devel
