Raymond Hettinger <raymond.hettin...@gmail.com> added the comment:
I'm familiar with the trade-offs (I'm the original designer of this code), but it is possible to use that reasoning to talk yourself into thinking that any optimization to code generation is worth it. The speed of the compile does matter as well (think about uses of exec() in dataclasses for example). Also, the level of complexity matters as well. The last time we introduced recursive passes for part of the peepholer (in constant folding), it took years to get it fully debugged and it caused a number of bug reports with respect to total compilation time. FWIW, Guido was never sold on the merits of having a peephole optimizer and the tool spent much of its life on the verge of being ripped-out. To accommodate his wishes and our design instincts, we agreed at the outset to keep this "dirt simple". (Put another way, for over a decade every developer who looked at this resisted going down this obvious line of development). That said, I'll leave it to Tim to decide. He helped talked Guido into letting me add this and he is the one who first proposed setting tight limits on how far we would go. (One last thought, be sure to coordinate with Serhiy who is actively transferring responsibilities upstream to the AST level manipulations so they can be analyzed at a higher level.) ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue37271> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
