[Python-ideas] disabling .pyc and .pyo files
rrr at ronadam.com
Sat Dec 12 17:59:47 CET 2009
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.
> 2009/12/8 Kristján Valur Jónsson <kristjan at ccpgames.com
> <mailto:kristjan at 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?
> Python-ideas mailing list
> Python-ideas at python.org <mailto:Python-ideas at python.org>
> Python-ideas mailing list
> Python-ideas at python.org
More information about the Python-ideas