You are right, I was suggesting the former.  From what cursory glance I had at the code it seemed simpler to not look for a .pyo file at all, rather than to add a special rule regarding its relation to a .py file.  That would also help rule out any timestamp problems.  But I‘m happy with whatever way we agree on to solve the „orphaned bytecode“ problem and glad to see that I‘m not the only one experiencing it.

 

Kristján

 

From: bcannon@gmail.com [mailto:bcannon@gmail.com] On Behalf Of Brett Cannon
Sent: 8. desember 2009 23:14
To: Kristján Valur Jónsson
Cc: python-ideas@python.org
Subject: Re: [Python-ideas] disabling .pyc and .pyo files

 

 

2009/12/8 Kristján Valur Jónsson <kristjan@ccpgames.com>

[SNIP] 

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.

 

Are you suggesting that the flag turn off reading *period*, or only if no source is available? I think you mean the former while Guido suggested the latter.

 

-Brett