homepage

Larry and I just chatted about this on IRC. Summary:
 1.) I was wrong about os.stat() affecting atime. I fired up a
 console session on Solaris to "prove" my atime observation
 only to find os.stat() had no impact on atime:
 % ./python
 Python 2.7.3+ (2.7:90a46f8943d0, Oct 18 2012, 11:09:15) [C] on sunos5
 Type "help", "copyright", "credits" or "license" for more information.
 >>> import os
 >>> fname = 'configure'
 >>> st0 = os.stat(fname)
 >>> os.utime(fname, (st0.st_atime, st0.st_mtime))
 >>> st0.st_atime
 1350571183.474864
 >>> st1 = os.stat(fname)
 >>> st1.st_atime
 1350571183.474864
 So, we can ignore my "but os.stat() affects atime!" noise
 earlier in this report.
 2.) Regardless of the underlying platform, the unit tests should
 test utime() with nano, micro and second resolution. However,
 the tests should be cognizant of the underlying platform's
 os.stat() versus os.utime() resolution when testing the actual
 results.
 That is, if you pass a nanosecond time to os.utime() on a platform
 that doesn't have underlying nanosecond support for utime (i.e. no
 utimensat()), then expect a microsecond resolution time back from
 stat().
 3.) Regarding fixed times versus re-setting the first results of our
 stat() call: no strong opinion either way -- the main objective
 is to ensure the tests have good coverage and are robust. So
 whatever gets the job done.