Nick Coghlan <ncogh...@gmail.com> added the comment: As Raymond noted though, some of the block stack fiddling doesn't make sense until after the bytecode has already been generated. It's OK to have multiple optimisers at different layers, each taking care of the elements that are best suited to that level.
And yes, an updated patch against the current tip would be good. Of my earlier review comments, the ones I'd still like to see addressed are: - finish clearing out the now redundant special casing of None/True/False - separating out the non-AST related compiler tweaks (i.e. 3b and 3c and the associated test changes) into their own patch (including moving the relevant tests into a separate @cpython_only test case) I'm still not 100% convinced on that latter set of changes, but I don't want my further pondering on those to hold up the rest of the patch. (they probably make sense, it's just that the AST level changes are much easier to review than the ones right down at the bytecode generation level - reviewing the latter means getting back up to speed on precisely how the block stack works and it will be a while before I get around to doing that. It's just one of those things where the details matter, but diving that deep into the compiler is such a rare occurrence that I have to give myself a refresher course each time it happens). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11549> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
