On Fri, 2 Jun 2000, Peter Funk wrote:
Moshe Zadka wrote:
Trusting OS-based mtimes for .pyc caching has some inherent problems. (Clock syncing and similar) Frankly, though I've never been bitten by this, it does give me an uncomfortable feeling. What if, instead, we'd use md5- or sha-based approach? I'm willing to bet that the 2^128 chance of problems is miniscule compared to the real problems clock syncing has already caused. (I think I remember some problem with .pyc's on IIS, but I may just be hallucinating)
The timestamp is returned by simply 'stat'ing the .py file. If you want more, you actually would have to open the .py files all the time. This would be trading a big performance penalty for a security, that will almost always not needed. In Unix many sub systems (for example 'make' depend on a monotone system clock. A random jumping clock would break many of them anyway.
He does have a point, but I think the wrong solution :-) While the clock may be monotonically increasing on one system, it isn't always the case when things like NFS come into play. I recall a case back '95 when I was editing a .py over an NFS mount and running the code on the target machine. The clocks on the two boxes were off by about three seconds. I was going thru the edit/run/edit/run cycle so quickly, that at one point, I saved a .py file that was older than the associated .pyc file. Needless to say, I was really confused that my recent edit didn't produce the desired result :-) Cheers, -g p.s. and no, I don't know why the internal timestamp didn't take effect -- Greg Stein, http://www.lyra.org/