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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4