n Feb 2, 3:16=A0pm, Antoine Pitrou <solip...@pitrou.net> wrote:
Larry Hastings <larry@...> 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. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org