[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/ULCEMMNQQ657LFEK6C5OX3S7ZL4YAV4E/
