Author eric.araujo
Recipients eric.araujo, jsjgruber, tarek
Date 2011-04-28.01:39:58
SpamBayes Score 8.76421e-12
Marked as misclassified No
Message-id <>
> I was trying to suggest that the move to stat.st_mtime in
> in the hg commit I mentioned be reverted back to use stat[ST_MTIME],
> thereby matching the other python releases and the old behavior (and
> matching It seems to me that would be the safest
> course when it comes to side-effects.

> If it were desired to determine which file was newer using sub-second
> values, perhaps that would make a reasonable change in distutils2,
> but files created with a few microseconds would have to be considered
> equivalent due to the reduced precision available in python floats
> (53 bits on my platform, if I understand correctly) as compared to
> the 64 bit precision used by some operating systems and file systems.
Interesting.  Can you open another bug, using type “feature request” and component “distutils2” so that we discuss that?  Alternatively, send an email to the-fellowship-of-the-packaging Google group (more people (including distutils wizards) follow the group than the bug tracker).

> However, I think I'd prefer to turn the decision and further process
> over to you, if you don't mind.
No problem.  Thanks to your patch and diagnosis, it should be easy to write a test and fix.  I hope you’ll be available to run the test on your machine.

> I thank you and your colleagues for your excellent work with python,
Thank you for doing your part as a user!  (It’s weird to see “colleagues” used with something that’s not a job.  We do this for fun, you know :)

> and with making it platform independent--a very difficult part of the
> work indeed.
Heh, the more I learn about Python, the more I hate hardware and operating systems :)
Date User Action Args
2011-04-28 01:40:00eric.araujosetrecipients: + eric.araujo, tarek, jsjgruber
2011-04-28 01:39:59eric.araujosetmessageid: <>
2011-04-28 01:39:58eric.araujolinkissue11933 messages
2011-04-28 01:39:58eric.araujocreate