[Python-ideas] Dump .pyo and the "optimize" flag

Floris Bruynooghe floris.bruynooghe at gmail.com
Wed Feb 3 00:10:30 CET 2010

n Feb 2, 3:16=A0pm, Antoine Pitrou <solip... at pitrou.net> wrote:
> Larry Hastings <larry at ...> writes:
> > I ask you: why gunk up the filesystem with two files when one would do
> > I propose we change the pyc file so it can contain multiple code
> > objects.
> I think we should dump the lie about "optimized" bytecode when the
> only optimization is that we strip some docstrings, disable asserts
> and set __debug__ to False.
> There should be only one possible bytecode file (XXX.pyc), and we
> could provide a "strip" tool (and/or corresponding function in the
> compileall module) for people for whom minimizing bytecode file size
> is important.
> Also, it would be interesting to know who bothers to use "python -O"
> (or "-OO").  I know I never use it.

We run -O in production so that __debug__ is set to False.  But I'd
much rather have only .pyc files and a strip tool + a flag (maybe
still -O) to switch between __debug__ being True or False (extra bonus
points for the strip tool being able to strip out "if __debug__:"
blocks too).

The reason I'd rather have only .pyc files is that now if you only
have .pyo files and don't start with -O you don't find the modules.
This is inconsistent as well: inside a zipfile the .pyo files are used
both when using -O and when not using that option.  Only an
inconvenience but still, it's something a customer doens't know if I
quickly ask the output of some "python -c 'something'" and forget to
tell them to use -O.


Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org

More information about the Python-ideas mailing list