Trent Nelson added the comment:
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.
----------
title: Numerous utime ns tests fail on FreeBSD w/ ZFS (update: and NetBSD w/
FFS, Solaris w/ UFS) -> Numerous utime ns tests fail on FreeBSD w/ ZFS
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue15745>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
