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