Am 03.02.2010 01:11, schrieb Ron Adam:
Antoine Pitrou 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.
If there was an easy way to get info from python on the status and location of the bytecode files it uses, it might not be so bad.
python -stat module.py
# python version # list of bytecode files, type, location
Then having .pyc also be used for optimized byte code could work.
On another note, it always seemed a bit backwards to me that the -OO wasn't the default output and if it were, we would have options to run in debug mode which would include 'docstrings', 'if debug ...' statements, and 'assert ...' statements, for testing purposes. <shrug>
Removal of docstrings should be separate from the rest, though. Quite a few programs would stop working properly without docstrings, with the docstring being used as a kind of easily introspectable annotation to a class or function.