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 ). It doesn't work this way in practice, though:

    python3.5
    >>> exec(compile("print(__debug__)", "exec", "exec", optimize=1))
    True

I'd recommend to fix either the documentation or the source code.

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.

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", optimize=0))
      1           0 LOAD_CONST               0 (1)
                  3 STORE_NAME               0 (x)
                  6 LOAD_CONST               1 (None)
                  9 RETURN_VALUE

    >>> dis.dis(compile("if __debug__: x = 1", "", "exec", optimize=1))
      1           0 LOAD_CONST               0 (None)
                  3 RETURN_VALUE

    >>> dis.dis(compile("x = __debug__", "", "exec", optimize=0))
      1           0 LOAD_NAME                0 (__debug__)
                  3 STORE_NAME               1 (x)
                  6 LOAD_CONST               0 (None)
                  9 RETURN_VALUE

    >>> dis.dis(compile("x = __debug__", "", "exec", optimize=1))
      1           0 LOAD_NAME                0 (__debug__)
                  3 STORE_NAME               1 (x)
                  6 LOAD_CONST               0 (None)
                  9 RETURN_VALUE

With the current design, an exec can override builtins.__debug__ in globals or locals:

    >>> exec("print(__debug__)", globals(), {"__debug__": "spam"})
    spam

I just opened bpo-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__` doesn't act as a compile time constant outside of `if:` and `while:` blocks, so the behavior is inconsistent for all other uses in the `compile` case where `optimize` doesn't match the main interpreter session, and inefficient for all other uses whether or not `compile` is involved.

If bpo-27169 is resolved as I suggested (or in some other similar way), it would also resolve this bug.

New changeset 3325a67 by Serhiy Storchaka in branch 'master':
bpo-27169: The __debug__ constant is now optimized out at compile time. (bpo-4880)
3325a67

Is it worth to backport this change?

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.

New changeset b82da9e by Serhiy Storchaka in branch '3.6':
[3.6] bpo-27169: The __debug__ constant is now optimized out at compile time. (GH-4880) (bpo-4882)
b82da9e

The backport to 3.6 is straightforward, but backporting to 2.7 would require larger changes.