[issue22091] __debug__ in compile(optimize=1)

Serhiy Storchaka added the comment: The backport to 3.6 is straightforward, but backporting to 2.7 would require larger changes. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed type: -> behavior versions: +Python 3.6, Python 3.7 -Python 3.4, Python 3.5

[issue22091] __debug__ in compile(optimize=1)

Serhiy Storchaka added the comment: New changeset b82da9ebb20053637e731fd40589e1e52f9f8f6e by Serhiy Storchaka in branch '3.6': [3.6] bpo-27169: The __debug__ constant is now optimized out at compile time. (GH-4880) (#4882) https://github.com/python/cpython/commit/b82da9ebb20053637e731fd40589

[issue22091] __debug__ in compile(optimize=1)

Change by Serhiy Storchaka : -- pull_requests: +4779 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue22091] __debug__ in compile(optimize=1)

STINNER Victor added the comment: > Is it worth to backport this change? It's an optimization, usually the answer is no. The change is short and can be seen as a bugfix, so it's up to you, it's ok to backport to 3.6, and maybe even 2.7, if it's not too hard to write the backport. --

[issue22091] __debug__ in compile(optimize=1)

Serhiy Storchaka added the comment: Is it worth to backport this change? -- ___ Python tracker ___ ___ Python-bugs-list mailing list

[issue22091] __debug__ in compile(optimize=1)

Serhiy Storchaka added the comment: New changeset 3325a6780c81f1ea51190370b5454879c4862a37 by Serhiy Storchaka in branch 'master': bpo-27169: The __debug__ constant is now optimized out at compile time. (#4880) https://github.com/python/cpython/commit/3325a6780c81f1ea51190370b5454879c4862a37

[issue22091] __debug__ in compile(optimize=1)

Change by Serhiy Storchaka : -- keywords: +patch pull_requests: +4775 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-

[issue22091] __debug__ in compile(optimize=1)

Josh Rosenberg added the comment: I just opened #27169: "__debug__ is not optimized out at compile time for anything but `if:` and `while:` blocks" as a more general case of this bug. This bug covers inconsistent behavior, but ultimately, it's caused by incomplete optimization: `__debug__` doe

[issue22091] __debug__ in compile(optimize=1)

eryksun added the comment: If __debug__ were referenced from the code object's co_consts instead of checking locals, globals and builtins (LOAD_NAME), then optimize=1 would work consistently for a given code object. Currently in 3.4.1: >>> dis.dis(compile("if __debug__: x = 1", "", "exec

[issue22091] __debug__ in compile(optimize=1)

SilentGhost added the comment: I can reproduce your example on 3.4, but for the comparison: >>> exec(compile("if __debug__: print(42)", "exec", "exec", optimize=1)) >>> exec(compile("if __debug__: print(42)", "exec", "exec", optimize=0)) 42 So, it's not as straightforward as one might imagine.

[issue22091] __debug__ in compile(optimize=1)

New submission from Armin Rigo: The documentation of the built-in compile() function is not 100% clear but I think it says that giving the "optimize=1" argument turns "__debug__" to false in the compiled code ( https://docs.python.org/3.5/library/functions.html?highlight=compile#compile ). I