[Python-Dev] Suggestion: stopping to trust os mtimes

[Peter Funk]

Hi,

Greg Stein:
> 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.

That is a well known and common trap.  Don't use NFS for Software
development unless you've read and understood RFC 868. ;-)

BTW.: Last year someone posted a pure Python implementation of RFC 868
time server and clients to c.l.p.  This might be useful on those WinXX boxes.

> 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 :-)

Sure. ;-)  But the same would have happenend, if you edited a .c source
file and if your target computer has C-compiler/linker, which is fast
enough to have a edit/compile/run cycle completed faster than the clock 
difference.  This is not uncommon today.

So the problem is not Python's fault and so I see no need to fix it there.
One thing could be added though: If Python 'stat's a .py file, which has
a time stamp in the future, it could issue a warning similar to that
displayed by 'make':
*** Warning: File `%s' has modification time in the future (%ld > %ld

Possibly this message could point the user to RFC 868 and the 'netdate' 
Unix command.  But that would be sugar on the cake.

Regards, Peter