| msg54874 - (view) |
Author: Toshio Kuratomi (abadger1999) |
Date: 2006-08-11 15:23 |
| If I invoke "python -OO" on a set of files, python creates a set of .pyo files. If I then realize this is an incredibly stupid thing to do because it removes the docstrings from the output and this program requires those docstrings python does not give me a method of overwriting the generated .pyos. I anticipated that running "python -O" would detect that the already generated .pyos were created in a different optimixation level and overwrite them with new .pyos. Barring that, I expected there to be a command line switch to tell python to overwrite the previously generated .pyo cache files. Finding neither, I realized that the only way to recover docstrings for people using python -O was to rm all the generated .pyo files. This seems like a bug or a missing feature. |
|
|
| msg54875 - (view) |
Author: Martin v. Löwis (loewis) *  |
Date: 2006-08-16 13:18 |
| Logged In: YES user_id=21627 This is a feature request; classifying it as such. See also PEP 304 (notice it has been withdrawn). |
|
|
| msg54876 - (view) |
Author: Toshio Kuratomi (abadger1999) |
Date: 2006-08-16 18:25 |
| Logged In: YES user_id=944205 Thanks. PEP 304 is a bit different. It is specifying the ability to read and write bytecode to a different directory structure while this is specifying that bytecode, once written is taken as canoncical even when options on the python commandline would change the bytecode that is written. Another solution in addition to those above would be writing files with different extensions for different optimization levels although this seems worse than either of the other two changes. |
|
|
| msg82217 - (view) |
Author: Daniel Diniz (ajaksu2) *  |
Date: 2009-02-16 05:18 |
| Confirmed in trunk. |
|
|
| msg116312 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-09-13 15:15 |
| How is this different than overwriting pyc files, except that there's probably less of a use case for pycs? IOW, if we were to do something about this, it should probably be an option to ignore any existing pyc (or pyo if -O is used) files and write new ones. It *could* be a command line switch, but honestly I think "find ... -exec rm {}" is just as good. I'd probably prefer adding a switch to Lib/py_compile's main to remove pyo/pyc's first or some such, but I'd still be -0 on supporting this directly in Python. |
|
|
| msg116324 - (view) |
Author: Toshio Kuratomi (a.badger) * |
Date: 2010-09-13 16:21 |
| Here's a usage where this matters. It's a simplification of the bug report that I got that prompted me to open this. Let's say I have the following code: /usr/lib/python2.7/site-packages/foo.py:: def help(): """I'm a little docstring, short and sweet""" print help.__doc__ /usr/bin/bar.py:: #!/usr/bin/python -tt import sys import foo if "--help" in sys.argv: foo.help() else: print "if you type --help, it's me you'll meet" The system administrator on this box comes along and runs:: $ PYTHONOPTIMIZE=2 bar.py if you type --help, it's me you'll meet No problems apparent there but then, the user comes along later and runs:: $ PYTHONOPTIMIZE=1 ./bar.py --help None At this point the end user opens a bug against my software telling me that --help is broken which confuses everyone. Not sure the best way to fix this -- ideas that pop into my head: These solutions don't lead to a bug report as python does the right thing on its own: * python reads and write separate pyo files for the different optimization levels (foo.pyo1 foo.pyo2) * python autodetects whether the cached .pyo was written for the current optimization level and disregards its existence if there's a mismatch (leading to rewriting if the user has permissions, otherwise, recompilation but no writing to disk). The following solution leads to a bug report but can be diagnosed with just the bug reporter. Note that PYTHONOPTIMIZE= /usr/bin/bar.py is almost as good in this situation: * python has a commandline switch to disregard current .pyo files. These solutions lead to a bug report but can be diagnosed with the cooperation of the system administrator in addition to the bug reporter: * Command line switch that overwrites the .pyo files * rm -rf *.pyo |
|
|
| msg116325 - (view) |
Author: Arfrever Frehtes Taifersar Arahesis (Arfrever) * |
Date: 2010-09-13 16:23 |
| compileall module supports -f (force) option, so you can use: python3.2 -O -m compileall -f ${files} |
|
|
| msg116326 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-09-13 16:42 |
| Uh, duh. Thanks for reminding me about that Arfrever! :) That should be everything Toshio needs I think. Plus this request is 4 years old. Closing as won't fix. |
|
|
| msg116328 - (view) |
Author: Toshio Kuratomi (a.badger) * |
Date: 2010-09-13 16:59 |
| It doesn't fix the problem as it falls into the third class of solutions (one that requires cooperation by the system administrator to diagnose and fix). OTOH, at this point in time I'm putting all of my packages in system packages where the .pyos are pregenerated correctly so I personally won't be getting new bug reports on this problem so I personally don't need to see this fixed anymore. |
|
|
| msg116337 - (view) |
Author: Barry A. Warsaw (barry) * |
Date: 2010-09-13 18:12 |
| Thanks Toshio, I get it now. I think pre-generating the proper pyo's is probably the best solution. |
|
|