Movatterモバイル変換
[0]ホーム
[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review
Guido van Rossumguido at python.org
Thu Feb 16 23:58:08 CET 2012
On Thu, Feb 16, 2012 at 2:48 PM, Victor Stinner<victor.stinner at gmail.com> wrote:> 2012/2/16 Guido van Rossum <guido at python.org>:>> On Thu, Feb 16, 2012 at 2:04 PM, Victor Stinner>> <victor.stinner at gmail.com> wrote:>>> It doesn't change anything to the Makefile issue, if timestamps are>>> different in a single nanosecond, they are seen as different by make>>> (by another program comparing the timestamp of two files using>>> nanosecond precision).>>>> But make doesn't compare timestamps for equality -- it compares for>> newer. That shouldn't be so critical, since if there is an *actual*>> causal link between file A and B, the difference in timestamps should>> always be much larger than 100 ns.>> The problem is that shutil.copy2() produces sometimes *older*> timestamp :-/ As shown in my previous email: in such case, make will> always rebuild the second file instead of only build it once.>> Example with two consecutive runs:>> $ ./python diff.py> 1329432426.650957952> 1329432426.650958061> 1.09E-7>> $ ./python diff.py> 1329432427.854957910> 1329432427.854957819> -9.1E-8Have you been able to reproduce this with an actual Makefile? What'sthe scenario? I'm thinking of a Makefile like this:a: cp /dev/null ab: a cp a bNow say a doesn't exist and we run "make b". This will create a andthen b. I can't believe that the difference between the mtimes of aand b is so small that if you copy the directory containing Makefile,a and b using a Python tool that reproduces mtimes only with usecaccuracy you'll end up with a directory where a is newer than n.What am I missing?-- --Guido van Rossum (python.org/~guido)
More information about the Python-Devmailing list
[8]ページ先頭