python -O does the following currently:

• completely ignores asserts
• sets the special builtin name __debug__ to False (which by default is True)

and when called as python -OO

• removes docstrings from the code

I don't know why everyone forgets to mention the __debug__ issue; perhaps it is because I'm the only one using it :) An if __debug__ construct creates no bytecode at all when running under -O, and I find that very useful.

Another use for the -O flag is that the value of the __debug__ builtin variable is set to False.

So, basically, your code can have a lot of "debugging" paths like:

if __debug__:
     # output all your favourite debugging information
     # and then more

which, when running under -O, won't even be included as bytecode in the .pyo file; a poor man's C-ish #ifdef.

Remember that docstrings are being dropped only when the flag is -OO.

assert statements are completely eliminated, as are statement blocks of the form if __debug__: ... (so you can put your debug code in such statements blocks and just run with -O to avoid that debug code).

With -OO, in addition, docstrings are also eliminated.

Using compile

I've come up with a solution using the built-in function compile, as follows.

Contents of the file main.py:

with open('test.py') as f:
    source_code = f.read()
compiled = compile(
    source_code,
    filename='test.py', mode='exec', optimize=2)
exec(compiled)

Contents of the file test.py:

if __debug__:
    print('Debug ON')
else:
    print('Debug OFF')

The output from running python main.py is:

Debug OFF

Possible values for the parameter optimize:

• -1: use same optimization level as the Python interpreter that is running the function compile
• 0: no optimization, and __debug__ == true
• 1: like -O, i.e., removes assert statements, and __debug__ == false
• 2: like -OO, i.e., removes also docstrings.

Don't know if it's the best option, just sharing if can be useful fo others.

Using subprocess.run

The subprocess-based approach is still more concise, and can be made portable by using sys.executable:

import subprocess
import sys

if not sys.executable:
    raise RuntimeError(sys.executable)
proc = subprocess.run(
    [sys.executable, '-OO', 'test.py'],
    capture_output=True, text=True)
if proc.returncode != 0:
    raise RuntimeError(proc.returncode)

The above code calls the function subprocess.run.

The check for the value of the variable sys.executable is motivated by the documentation of CPython:

If Python is unable to retrieve the real path to its executable, sys.executable will be an empty string or None.

The check is implemented with a raise statement, instead of an assert statement, in order to check also in cases that the above Python code is itself run with optimization requested from Python, e.g., by using python -O or python -OO or the environment variable PYTHONOPTIMIZE.

When optimization is requested, assert statements are removed.

Using raise statements also enables raising an exception other than AssertionError, in this case RuntimeError.

For running Python code that is within a function inside the same source file (i.e., inside main.py, not inside test.py), the function inspect.getsource can be used, together with the option -c of python.

By the way better answers are welcome!

In Python 2.7, -O has the following effect:

• the byte code extension changes to .pyo
• sys.flags.optimize gets set to 1
• __debug__ is False
• asserts don't get executed

In addition -OO has the following effect:

• sys.flags.optimize gets set to 2
• doc strings are not available

To verify the effect for a different release of CPython, grep the source code for Py_OptimizeFlag.

Link to official documentation: https://docs.python.org/2.7/tutorial/modules.html#compiled-python-files

You can set the PYTHONOPTIMIZE environment variable if you really understand what you are doing.

# e.g.
# same as -O
export PYTHONOPTIMIZE=1
# same as -OO
export PYTHONOPTIMIZE=2

Reference: Python doc: Command line and environment

PYTHONOPTIMIZE

If this is set to a non-empty string it is equivalent to specifying the -O option. If set to an integer, it is equivalent to specifying -O multiple times.

But normally you should never do it !!!

Deestan's answer for another SO question "Best practice for Python Assert" is really great:

Asserts should be used to test conditions that should never happen.

The purpose is to crash early in the case of a corrupt program state.

Usually a django application uses many other libraries. When something critical happens, and those libraries believe that the application should crash immediately, they follow the best practice above and use asserts. You don't want to break that.