[Python-ideas] Importing orphaned bytecode files
ben+python at benfinney.id.au
Wed Dec 9 06:38:32 CET 2009
Guido van Rossum <guido at python.org> writes:
> On Tue, Dec 8, 2009 at 6:28 PM, Ben Finney <ben+python at benfinney.id.au> wrote:
> > this source file would, if compiled, result in a bytecode file
> > replacing this one
> > Nowhere there is there anything about the resulting bytecode files
> > being equivalent. I'm limiting the check only to whether the
> > resulting bytecode file would *replace* the existing bytecode file.
> > This doesn't require knowing anything at all about the contents of
> > the current bytecode file; indeed, my intention was to phrase it so
> > that it's checked before bothering to open the existing bytecode
> > file.
> > Is there a better term for this? I'm not well-versed enough in the
> > Python import internals to know.
> If there was a corresponding source file, it would have been found
> first -- and the bytecode file would be used *if* it matches the
> source file (by comparing a timestamp in the bytecode file's header to
> the actual mtime of the source file).
Right, that's what I thought. I was only looking for a way to say “only
use a bytecode file if the corresponding source code file exists”, and
then trying to define “corresponding source code file”.
It appears that all I'm doing is confusing the issue, probably because
my understanding of the terminology is fuzzy. I hope someone else can
word it better, so the question of “which file, exactly, are we saying
must exist?” is well answered.
> So I'm not sure what there is to do apart from *not* using "lone"
> bytecode files. (The latter was actually added as a feature at some
> point so I betcha it's easy to make it conditional on a flag.)
I hope your instinct is right, and I betcha it is too.
\ “Intellectual property is to the 21st century what the slave |
`\ trade was to the 16th.” —David Mertz |
More information about the Python-ideas