> You started your msg by saying "we moved the optimization", but that's not so: the optimization was eliminated. So just finish "moving" it ;-)
PR14116 was "finishing" the moving by adding JUMPS (a weaker optimization but still an optimization). > We should revert the change until someone (not me ;-) ) thinks harder about whether it's possible to get both. There doesn't seem to be, e.g., a conceptual problem with simply throwing away "if 0:" subtrees from the AST before generating code, or from snipping the "if 1:" guard off an "if 1:" block. Ok, these were very good points. I am convinced. I agree that the better thing to do at this pointis to revert this until we can think this a bit more :) I have made a PR to revert the change. On Fri, 5 Jul 2019 at 23:27, Tim Peters <tim.pet...@gmail.com> wrote: > [Pablo Galindo Salgado <pablog...@gmail.com>] > > Recently, we moved the optimization for the removal of dead code of the > form > > > > if 0: > > .... > > > > to the ast so we use JUMP bytecodes instead (being completed in > PR14116). The > > reason is that currently, any syntax error in the block will never be > reported. > > For example: > > "Any syntax error" is way overstated. "Almost all" syntax errors will > be reported. The ones that won't be aren't "really" about syntax (as > most people view it). but more restrictions on the context in which > certain statements can appear: > > > if 0: > > return > > > > if 1: > > pass > > else: > > return > > > > while 0: > > return > > > > > > at module level do not raise any syntax error (just some examples), > > Whereas in function scope, those are all fine, with "0" or "1". It's > the "module level" context that matters to those. Regardless of > context, a syntax error that's actually about syntax ;-) is reported: > > if 0: > x + > > > > In https://bugs.python.org/issue37500 it was reported > > that after that, code coverage will decrease as coverage.py sees these > > new bytecodes (even if they are not executed). In general, > > the code object is a bit bigger and the optimization now it > > requires an JUMP instruction to be executed, but syntax errors > > are reported. > > And I added other gripes to the report. > > I have one file (temp.py) using "if 0:" over 400 times. When I need > to write a small program or example (for, e.g. a StackOverflow > answer), I add a new "if 1:" block at the end, fiddle with it until > it's ready, then change the "1:" to "0:". So the snippets stay around > forever, but are effectively commented out so have no effect > (unless/until they're needed again). > > There are, of course, other ways to comment them out, but none so > convenient. For example, under the "if 1:" block, the code is already > indented 4 spaces, so can be pasted exactly as-is into a StackOverflow > answer. > > But it doesn't really matter what I happen to do: I'm just one of > millions of users, who have come to rely on this stuff for way over a > decade. > > > The discussion on issue 37500 is about if we should prioritize the > optimization > > or the correctness of reporting syntax errors. In my opinion, > > Which doesn't really make sense unless it's logically _necessary_ to > "pick just one - you can't have both". > > > SyntaxErrors should be reported with independence of the value of > variables > > (__debug__) or constant as is a property of the code being written not > of the > > code being executed. Also, as CPython is the reference implementation of > Python, > > the danger here is that it could be interpreted that this optimization > is part of the > > language and its behavior should be mirrored in every other Python > implementation. > > It's been that way for at least 15 years (since Python 2.4, so it's > hard to be worried about that now. Indeed, Armin Rigo posted the > original example, and he wasn't fooled a bit about intent ;-) > > > Elsewhere we have always prioritize correctness over speed or > optimizations. > > When they're irreconcilably in conflict, and the cost of correctness > isn't "just too much", sure. > > > > I am writing this email to know what other people think. Should we > revert the change > > and not report Syntax Errors on optimized blocks? Someone sees a viable > way of > > reporting the errors and not emitting the bytecode for these block? > > We should revert the change until someone (not me ;-) ) thinks harder > about whether it's possible to get both. There doesn't seem to be, > e.g., a conceptual problem with simply throwing away "if 0:" subtrees > from the AST before generating code, or from snipping the "if 1:" > guard off an "if 1:" block. > > You started your msg by saying "we moved the optimization", but that's > not so: the optimization was eliminated. So just finish "moving" it > ;-) >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/YTXWYO7CMJLWE27RBKQPOND7JNRLV6Z2/
