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.

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

This flag enables Profile guided optimization (PGO) and Link Time Optimization (LTO).

Both are expensive optimizations that slow down the build process but yield a significant speed boost (around 10-20% from what I remember reading).

The discussion of what these exactly do is beyond my knowledge and probably too broad for a single question. Either way, you can read a bit about LTO from the the docs on GCC which has an implementation for it and get a start on PGO by reading its wiki page.

Also, see the relevant issues opened on the Python Bug Tracker that added these:

• Issue 24915: Profile Guided Optimization improvements (better training, llvm support, etc) (Added PGO.)
• Issue 25702: Link Time Optimizations support for GCC and CLANG (Added LTO.)
• Issue 26359: CPython build options for out-of-the box performance (Adds the --enable-optimizations flag to the configure script which enables the aforementioned optimizations.)

As pointed out by @Shuo in a comment and stated in Issue 28032, LTO isn't always enabled with the --enable-optimizations flag. Some platforms (depending on the supported version of gcc) will disable it in the configuration script.

Future versions of this flag will probably always have it enabled though, so it's pretty safe to talk about them both here.

It's not much compilation per se (CPython does compile to bytecode), but the extremely dynamic nature of the language hampers "traditional" optimizations, which are guided by invariants which are difficult to check at compile time in Python, because the semantics of the language is such that most information about what the code is actually supposed to do is only available at runtime.

Your if condition == True: example is a good one: that comparison could be optimized only if the compiler could prove that condition is always a boolean, which is a non-trivial task if it derives from anything but literals in the current scope - and if it could prove that, at runtime, nobody managed to overwrite True with something else (possible only in Python 2 IIRC).

Mind you, some type inference is possible, and it's actually how code completion tools like Jedi work; however, Jedi can take some shortcuts and assume e.g. some kind of standard environment, while the interpreter has to cope with the most bizarre modifications to the globals that the language do allow.

So, in general CPython does not try very hard to optimize anything - actually, it doesn't seem to do any kind of "smart" code analysis, AFAICT they mostly try to build an efficient but "mostly vanilla" interpreter. So, expect to pay almost exactly for what you write, there's no optimizer to save sloppy code.

By the way, your and example is not an optimization done by the interpreter, it's just how the semantic of the operator is defined (and it's quite crucial that it's specified that and and or do short circuit evaluation and it's not an optional "optimization", since it could alter the observable behavior of the program if the right hand operand had side effects).

A better approach for a language that dynamic is instead that of a tracing JIT - the interpreter lets the code run for a while, and observes the invariants that seem to hold well (for example, condition seems to always be a boolean, True is always True, some variable is always an integer, ...), and then uses this information to compile to machine code an optimized version of the code. This is let run as long as the invariants above do hold - but as soon as one of the premises used to compile the optimized version is broken, the execution goes back into interpreted mode, and tracing begins again to find out if a new optimized version can be built.

Thus, the typical case is optimized well, applying the usual optimization techniques, but whenever something bizarre (but allowed by the language) happens, the runtime can fallback to the regular "literal" bytecode interpretation.

This is the approach used to squeeze good performance from most dynamic languages (most modern JavaScript engines use some variation of this basic approach), and in Python is used in PyPy.