Because you can use coding and then it's somewhat automatic?
But you can do sth similar on AST level, namely installing a meta path finder, i.e. an import module hook which does the AST transformation automatically (https://docs.python.org/3/library/sys.html#sys.meta_path).
Then, there is also the new frame evaluation API (https://peps.python.org/pep-0523/), which allows you to dynamically rewrite bytecode. This has been used by PyTorch 2.0 for torch.compile.
Repo if anyone is interested: https://github.com/ckw017/blursed
This was inspired by a way less silly usecase, future f-strings, which added f-string support to older versions of Python in a similar way using codecs: https://github.com/asottile-archive/future-fstrings
It's done with AST manipulation as well, but on a larger scale and completer functionalities.
This seems like an interesting avenue for static analysis tools, code generators, (etc.) to explore. Is it a viable approach?
I'd be interested in some analysis on this as a mechanism: performance, maintability, etc. wise.
The "dont do this" argument writes itself; nevertheless, its worth exploring.
The idea of using (abusing in fact) codecs to pre-process python code before it gets to the actual python interpreter is just fantastic!
I'm starting to think of all the terrible things I'm going to be able to do with this to work around things that have annoyed me for years in python.
[EDIT]: I'm thinking one can probably plug the C preprocessor in python now ... oh the sheer joy :D
I wonder if the codec could use python's lexer (assuming it's exposed) to parse the for loops and nothing else. Then replace the loops with a placeholder, and then replace the placeholder in the AST after a parse. Might be cleaner than source->source transform by the codec, maybe not.
1. I wish more HN posts ended in "for fun" -- so much of what makes being a progammer fun and enjoyable is plumbing the depths of what is possible, not because it's "best practice" or whatever. I think these types of forrays are where true mastery comes from.
2. The less reserved keywords a language has, the better. It makes things like this easier. Years ago I figured out how to implement Goto in Smalltalk "for fun". It was easier because Smalltalk had less reserved keywords.
(defmacro cfor [initialize condition advance #* body]
`(do ~initialize
(while ~condition (do [email protected] ~advance))))
(cfor (setv i 0) (< i 10) (+= i 1)
(print i))
Beg your pardon, http://entrian.com/goto/ exists.
You really do need to be modifying the AST and not just applying a regex to the source code text. This can be a challenge if you want to modify python syntax as you first need to get an AST you can modify, personally I recommend starting with the LARK library and modifying the python syntax grammer it includes.
https://lark-parser.readthedocs.io/en/latest/examples/advanc...
I use similar techniques to transpile openscad code into a python AST in my "pySdfScad" project, while still theoretically getting the benefits of fancy tracebacks and debugging and the like. Probably should have gone with a simple parser instead, but what can you do.
I think they should have stopped at the "cursed way" and not the "truly cursed way", if they really wanted the syntax changes than having your own python parser like the LARK implementation I mention above is a must.