[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: I will close this for now, we can revisit this if we find a better solution for the issue. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

miss-islington added the comment: New changeset 9ea738e580f58c3d2f9b0d56561d57b9e9412973 by Miss Islington (bot) in branch '3.8': bpo-37500: Make sure dead code does not generate bytecode but also detect syntax errors (GH-14612)

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by miss-islington : -- pull_requests: +14768 pull_request: https://github.com/python/cpython/pull/15002 ___ Python tracker ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Serhiy Storchaka added the comment: I am fine with backporting the 3.9 solution to 3.8. Sorry for the delay. -- ___ Python tracker ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Łukasz Langa added the comment: Victor closed the 3.8 backport, stating on GitHub: "I closed the 3.8 backport (without merging it), until we agree on what should be done." This is marked as release blocker. I will be releasing 3.8b3 as is, please decide what to do here before b4, I will

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by miss-islington : -- pull_requests: +14576 pull_request: https://github.com/python/cpython/pull/14780 ___ Python tracker ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

miss-islington added the comment: New changeset 18c5f9d44dde37c0fae5585a604c6027825252d2 by Miss Islington (bot) (Pablo Galindo) in branch 'master': bpo-37500: Make sure dead code does not generate bytecode but also detect syntax errors (GH-14612)

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Ned Deily : -- keywords: -3.7regression nosy: -ned.deily ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Deily added the comment: New changeset 4834c80d799471a6c9ddaad9c5c82c8af156e4fd by Ned Deily (Pablo Galindo) in branch '3.7': [3.7] bpo-37500: Revert commit 85ed1712e428f93408f56fc684816f9a85b0ebc0 (GH-14605)

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Yep, that is more or less the approach in PR14612. What I tried to achieve there is also minimize the amount of changes to make the pass for errors non intrusive. -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Guido van Rossum added the comment: Sure seems to me as if we need to have a separate pass that looks for out-of-place `return`, `yield`, `break` and `continue`, run before the optimization removes `if 0:` blocks etc. -- nosy: +gvanrossum ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > Which should be fixed, if possible. But, as damage goes - sorry! - it just > seems minimal to me. I think I failed to express myself correctly there :( I have absolutely no problem with the way that behaves currently, I just wanted to point out

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: > we could say that it does not matter if > > def f(): > if 0: > yield > > should be or not a generator Slippery slope arguments play better if they're made _before_ a decade has passed after the slope was fully greased. There's nothing accidental about

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > So, to my eyes, absolutely nothing of the optimization remained. At least > not in the example Ned posted here. This is because his example did not include the changes in PR14116 that implemented that. --

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: > Using jumps is not removing the optimization > entirely, is just a weaker and more incomplete > way of doing the same. Sorry, I'm afraid I have no idea what that means. The generated code before and after was wildly different, as shown in Ned's original

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: I think I have found a simple way to make everyone happy: we can add a new field to the compiler that tells it to not emit bytecode. In this way we can detect errors by walking the blocks but no bytecode will be emitted. I have updated PR 14612 to

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > It's the expected result of fixing a bug _by_ eliminating the optimization > entirely. Using jumps is not removing the optimization entirely, is just a weaker and more incomplete way of doing the same. The optimization introduced the bug in the

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Tim, you made very good points in you email to Python-dev. I am convinced 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, could you review it, please? --

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: > This is the expected result of fixing a bug that has been > open since 2008 It's the expected result of fixing a bug _by_ eliminating the optimization entirely. It's not an expected result of merely fixing the bug. It's quite obviously _possible_ to note

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +14426 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14612 ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > I see optimizing away 'if __debug__: ...' clauses, when __debug__ is False > (and 0) as currently documented language behavior, not a 'deep implementation > detail'. https://docs.python.org/3/reference/simple_stmts.html#the-assert-statement I don't

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > In either case, I don't think it should have been applied as is in b2 Just to clarify: this was added before beta2. -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Deily added the comment: For the record, this change in behavior was originally backported to the 3.7 branch and appeared in 3.7.4rc1 and rc2. Now that the compatibility issues are clearer, it will be reverted for 3.7.4 final and will not be considered for future 3.7.x releases.

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Paul Ganssle added the comment: > CPython has acted the current way for about 15 years (since 2.4 was > released), and this is the first time anyone has raised an objection. This is the expected result of fixing a bug that has been open since 2008 (11 years), which itself was noticed

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Terry J. Reedy added the comment: I agree with Tim. Detect SyntaxErrors in dead code if you can, but don't change the current code deletion, at least not without proper discussion (which Pablo just started on pydev). The latter is what I consider to be a release blocker needing release

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > CPython has acted the current way for about 15 years (since 2.4 was > released), and this is the first time anyone has raised an objection. Although I tend to agree with your words, I have to insist that correctness in the reference implementation

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: There's "correctness" that matters and "correctness" that's merely pedantic ;-) CPython has acted the current way for about 15 years (since 2.4 was released), and this is the first time anyone has raised an objection. That's just not enough harm to justify

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: I have opened a thread in Python dev: https://mail.python.org/archives/list/python-...@python.org/thread/RHP4LTM4MSTAPJHGMQGGHERYI4PZR23R/ -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Mark Williams added the comment: As a user of Python who maintains at least one large code base, I rely on coverage to limit the damage my changes can inflict. Some of the code I maintain uses __debug__; I would not expect moving to 3.8 to be the cause of reduced line coverage in that

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: CPython being the reference implementation of Python, people could interpret that this optimization is part of the language and its behavior should be mirror in every other implementation. That's why under my understanding, correctness should always

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > No tests or jumps at all. That made the optim... I understand that, but we would need a way of reporting syntax errors in blocks even if they will not be executed. Although I agree with your analysis, correctness should be prioritized over

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Tim Peters added the comment: I hate this change :-( The code generated for something like this today: def f(): if 0: x = 1 elif 0: x = 2 elif 1: x = 3 elif 0: x = 4 else: x = 5 print(x) is the same as for: def f(): x = 3

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: > To add to the confusion, the treatment of "if __debug__:" and "if not > __debug__:" is now asymmetric: After the code in PR 14116 this becomes: 5 0 LOAD_GLOBAL 0 (print) 2 LOAD_CONST 1 ('debug')

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: >Before this change, code could have had an unreported SyntaxError, but it was >code that was being discarded by the optimizer anyway if __debug__ can a valid form of if 0 and therefore any syntax error will not be reported until that branch becomes

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: To add to the confusion, the treatment of "if __debug__:" and "if not __debug__:" is now asymmetric: Here is debug.py: import dis import sys print(sys.version) def f(): if __debug__: print("debug") else: print("not debug") if

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: I can see the logic of the argument that says the code exists, and should be measured. But this is changing behavior that has been in place for at least 15 years. Before this change, code could have had an unreported SyntaxError, but it was code that was

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Stefan Behnel added the comment: > it should not be rely upon IMHO, the correct behaviour under coverage analysis is to keep the code and not discard it. After all, it is code that exists, and that is not being executed, so it should count as uncovered code. The fact that some Python

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: I don't know what you mean by, "it should not be rely upon." Are you saying that in 3.8 you want to keep the lines in the compiled bytecode? Do you understand the implications for coverage measurement? -- ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

miss-islington added the comment: New changeset 7d93effeb4f8e86dfa283f2376ec5362275635c6 by Miss Islington (bot) (Pablo Galindo) in branch '3.7': [3.7] bpo-37500: Revert commit 85ed1712e428f93408f56fc684816f9a85b0ebc0 (GH-14605)

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Pablo Galindo Salgado : -- Removed message: https://bugs.python.org/msg347367 ___ Python tracker ___ ___ Python-bugs-list

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Ned, I have prepared PR14605 for the 3.7 branch to revert 85ed1712e428f93408f56fc684816f9a85b0ebc0. As this is somehow changing behavior in the 3.7 series, I think is the best course of action for 3.7. For 3.8 the proposed way to do this is now using

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Pablo Galindo Salgado added the comment: Ned, I have prepared PR14605 for the 3.7 branch to revert 85ed1712e428f93408f56fc684816f9a85b0ebc0. As this is somehow changing behavior in the 3.7 series, I think is the best course of action for 3.7. For 3.8 the proposed way to do this is not using

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Pablo Galindo Salgado : -- keywords: +patch pull_requests: +14420 stage: -> patch review pull_request: https://github.com/python/cpython/pull/14605 ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: 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

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Deily added the comment: How serious a regression is this? We still have time to revert the 3.7 commit of Issue1875 (85ed1712e428f93408f56fc684816f9a85b0ebc0) from 3.7.4 final if we act immediately. -- nosy: +ned.deily versions: +Python 3.7

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: Since this was backported to 3.7 but not yet released, I'm adding 3.7regression. -- keywords: +3.7regression ___ Python tracker ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Serhiy Storchaka added the comment: The root cause is PR 13332 for issue1875. -- ___ Python tracker ___ ___ Python-bugs-list

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Aldwin Pollefeyt added the comment: FWIW: this is probably since PR14099 -- nosy: +aldwinaldwin ___ Python tracker ___ ___

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Karthikeyan Singaravelan added the comment: Not sure if related there were some changes done to __debug__ related checks with issue37269 -- nosy: +xtreak ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Ned Batchelder added the comment: BTW, the same regression applies to "if not __debug__:" . Python3.8.0b1 optimized these away, but b2 does not. That optimization was new in 3.7.0a4 -- ___ Python tracker

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

Change by Karthikeyan Singaravelan : -- nosy: +pablogsal, serhiy.storchaka ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue37500] 3.8.0b2 no longer optimizes away "if 0:" ?

New submission from Ned Batchelder : CPython 3.8.0b2 behaves differently than previous releases: it no longer optimizes away "if 0:" branches. This is something that has been done since at least 2.4. It was done in 3.8.0b1, but no longer is. Was this a purposeful change? Why? It seems like