Guido van Rossum <guido@python.org> writes:
On Tue, Dec 8, 2009 at 6:28 PM, Ben Finney <ben+python@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 | _o__) | Ben Finney