Brett Cannon wrote:
I don't know about the rest of you, but I think it's PEP time as the conversation seems to have run its course. Looks like the popular options are a flag to not read any bytecode or to only read bytecode if the source is also available. And then whether the default behavior should change or not.
A few additional thoughts... Could the existing -B flag be extended to not read bytecode? It might be considered a bug if bytecode is read when the -B option is used to prevent writing of bytecode. Is there a use case for forcing the use of old bytecode? What was the original intent of the -B flag? Would adding a flag to force the writing of bytecode do what is needed? It would generate a noisy fail if a source file is moved or missing and renew old bytecode files. These two together would give read_none and write_all bytecode modes. With the default mode as the write as needed mode. It may be good to have A utility script in the python tools directory to find and/or remove orphaned bytecode. I'm not sure that just deleting all .py(co) files is always a good idea. A more off the wall random thought ... It might be nice in the future to have all bytecode in a single directory or package combined into a single byte_cache.py(co) file. I think Writing all and reading None bytecode files makes good sense in this context. Ron
2009/12/8 Kristján Valur Jónsson
mailto:kristjan@ccpgames.com> Hello there.
We have a large project involving multiple perforce branches of hundreds of .py files each.
Although we employ our own import mechanism for the bulk of these files, we do use the regular import mechanism for an essential core of them.
Repeatedly we run into trouble because of stray .pyo (and/or .pyc) files. This can happen for a variety of reasons, but most often it occurs when .py files are being removed, or moved in the hierarchy. The problem is that the application will happily load and import an orphaned .pyo file, even though the .py file has gone or moved.
I looked at the import code and I found that it is trivial to block the reading and writing of .pyo files. I am about to implement that patch for our purposes, thus forcing recompilation of the .py files on each run if so specified. This will ensure that the application will execute only the code represented by the checked-out .py files. But it occurred to me that this functionality might be of interest to other people than just us. I can imagine, for example, that buildbots running the python regression testsuite might be running into problems with stray .pyo files from time to time.
Do you think that such a command line option would be useful for Python at large?
Cheers,
Kristján
_______________________________________________ Python-ideas mailing list Python-ideas@python.org mailto:Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas
------------------------------------------------------------------------
_______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas