[Python-ideas] disabling .pyc and .pyo files
Guido van Rossum
guido at python.org
Tue Dec 8 20:10:00 CET 2009
Agreed. I wonder if this functionality ought to be opt-in instead of
opt-out? The only use cases I am aware of are software vendors who
don't want to distribute their source (a near-extinct breed for
sure...) or people with absurdly small disks (ditto).
2009/12/8 Jesse Noller <jnoller at gmail.com>:
> 2009/12/8 Kristján Valur Jónsson <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
> FWIW: I've been bitten by this more than once, especially on Django
> projects, mainly during the development cycle.
> Python-ideas mailing list
> Python-ideas at python.org
--Guido van Rossum (python.org/~guido)
More information about the Python-ideas