[Python-Dev] PEP 410 (Decimal timestamp): the implementation is ready for a review (original) (raw)

Guido van Rossum guido 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-8

Have you been able to reproduce this with an actual Makefile? What's the scenario? I'm thinking of a Makefile like this:

a: cp /dev/null a b: a cp a b

Now say a doesn't exist and we run "make b". This will create a and then b. I can't believe that the difference between the mtimes of a and b is so small that if you copy the directory containing Makefile, a and b using a Python tool that reproduces mtimes only with usec accuracy 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-Dev mailing list