[Python-ideas] disabling .pyc and .pyo files

Ron Adam 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.

Ron






> 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?
> 
>      
> 
>     Cheers,
> 
>     Kristján
> 
> 
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto:Python-ideas at python.org>
>     http://mail.python.org/mailman/listinfo/python-ideas
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas



More information about the Python-ideas mailing list