Message3157

Author pjenvey
Recipients pjenvey
Date 2008-04-17.06:04:27
SpamBayes Score 0.0045544347
Marked as misclassified No
Message-id <1208412268.17.0.561485304182.issue1024@psf.upfronthosting.co.za>
In-reply-to
Content
CPython .pyc files include the modified time of the .py file it was 
created from. CPython then knows that the .pyc is up to date by 
comparing the .py's mtime against the .pyc's stored value

Jython doesn't store this value in $py.class, all it does is compare the 
$py.class's mtime against .py on the filesystem

This doesn't seem like a big deal but it makes us incompatible with 
CPython

I ran into a situation where this caused a hard to diagnose problem: a 
test would generate a sample.py file and invoke a separate process to 
import it. Then it would copy a different version of the same sample.py 
file over, and invoke another process that imported it.

The first $py.class generated actually ended up having the same mtime as 
the second .py that was copied over. Because we only compare the mtimes 
of the files themselves, Jython assumed the bytecode was up to date when 
it wasn't, the second .py wasn't compiled/used (causing a very weird 
bug)

In this situation in CPython, the first .pyc might have the same mtime 
as the second .py, like our situation above in Jython, but CPython would 
actually be comparing the second .py's mtime against the mtime of the 
first .py, which in this situation were reliably different.

We need to work this way too to avoid surprises like this with code 
written for CPython
History
Date User Action Args
2008-04-17 06:04:28pjenveysetspambayes_score: 0.00455443 -> 0.0045544347
recipients: + pjenvey
2008-04-17 06:04:28pjenveysetspambayes_score: 0.00455443 -> 0.00455443
messageid: <1208412268.17.0.561485304182.issue1024@psf.upfronthosting.co.za>
2008-04-17 06:04:28pjenveylinkissue1024 messages
2008-04-17 06:04:27pjenveycreate