Author jsjgruber
Recipients eric.araujo, jsjgruber, tarek
Date 2011-04-27.04:29:49
SpamBayes Score 0.0
Marked as misclassified No
Message-id <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
In-reply-to
Content
In researching a bug I was surprised that a newly created file was being replaced when being processed a second time (it shouldn't have been processed a second time). 

I tracked the surprise to diff Lib/distutils/dep_util.py @ 57642:9211a5d7d0b4 where a comparison with a resolution of 1 second was replaced by a floating point comparison, though the new file was copied by file_util.py which tried to preserve the time using a method accurate to only 1 second (truncating the fraction). Since a new file with a truncated modification time looks older than an older file with a full precision stamp the problem resulted.

(For convenience--stat.st_mtime is floating point, stat[ST_MTIME] is integer seconds unless os.stat_float_times has been called to change the floating point behavior.

Using all floating point doesn't resolve the issue as OS timestamped files can have more resolution than python floating point may hold, again causing truncation and confusion. For reference see Python issue 10148.

In my humble opinion time setting and comparison should all be done consistently, and, if sub-second comparisons are desired, some fuzz should be used such that the comparison makes sense for the platform with the least amount of precision available with its floating point implementation.

I briefly looked at branches other than 2.7 and they don't seem to have the above change.

Probably of minor importance in most cases.

Thanks all for the good work, all. I've been learning python and I love it!
History
Date User Action Args
2011-04-27 04:29:51jsjgrubersetrecipients: + jsjgruber, tarek, eric.araujo
2011-04-27 04:29:50jsjgrubersetmessageid: <1303878590.96.0.749813744893.issue11933@psf.upfronthosting.co.za>
2011-04-27 04:29:50jsjgruberlinkissue11933 messages
2011-04-27 04:29:49jsjgrubercreate