Message3157
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 |
|
Date |
User |
Action |
Args |
2008-04-17 06:04:28 | pjenvey | set | spambayes_score: 0.00455443 -> 0.0045544347 recipients:
+ pjenvey |
2008-04-17 06:04:28 | pjenvey | set | spambayes_score: 0.00455443 -> 0.00455443 messageid: <1208412268.17.0.561485304182.issue1024@psf.upfronthosting.co.za> |
2008-04-17 06:04:28 | pjenvey | link | issue1024 messages |
2008-04-17 06:04:27 | pjenvey | create | |
|