> Until a solution which makes everyone happy can be found, I suggest to
move back to the status quo: revert the change.

>More people seems to expect "if 0: ..." to be removed, than people who
care of syntax errors on "if 0".

I don't think this is that clear. As Paul wrote on the issue this is the  result of fixing a bug that has been open since
2008 (11 years), which itself was noticed independently, also in 2008 (#1875 and #1920, respectively).
He also independently discovered the same issue last year when writing some tests for IPython.

https://bugs.python.org/msg347394

On Fri, 5 Jul 2019 at 23:10, Victor Stinner <vstinner@redhat.com> wrote:
Hi,

Until a solution which makes everyone happy can be found, I suggest to
move back to the status quo: revert the change.

More people seems to expect "if 0: ..." to be removed, than people who
care of syntax errors on "if 0".

--

Would it be possible to detect if the "if 0" block would raise a
syntax error, and only remove it if it doesn't raise a syntax error?

That's the approach I chose in my fatoptimizer project which is
implemented as an AST optimizer:
https://github.com/vstinner/fatoptimizer/blob/master/fatoptimizer/dead_code.py

See the tests to see which cases are *not* optimized:
https://github.com/vstinner/fatoptimizer/blob/master/test_fatoptimizer.py#L2428

Some examples (the "dead code elimitaiton" is not only about "if 0",
but also "while 0", dead code after return, etc.):

    self.check_dont_optimize("""
        def func():
            if 0:
                yield
    """)

    self.check_dont_optimize("while 1: x = 1")

    self.check_dont_optimize("""
        def func(obj):
            return
            if 0:
                yield from obj
    """)

    self.check_dont_optimize("""
        try:
            pass
        except Exception:
            yield 3
    """)

See also the doc:
https://fatoptimizer.readthedocs.io/en/latest/optimizations.html#dead-code

--

About code coverage, it seems like -X noopt would help:
https://github.com/python/cpython/pull/13600

But I'm not sure anymore after Ned Batchelder wrote:

"The real-word implications from my world are this: if your code has
"if 0:" clauses in it, and you measure its coverage, then because the
lines have not been optimized away, coverage.py will think the lines
are a possible execution path, and will be considered a miss because
they are not executed.  This will reduce your coverage percentage."
https://bugs.python.org/issue37500#msg347362

Does it mean that coverage.py will report even more "false positive"
using -X noopt?

Victor