Michael Glassford schrieb: > Although not mentioned in the Python 2.5 News, apparently there was a > similar change on Mac that I'm having some problems with. On the Mac, > just as on Windows, os.stat().st_mtime now returns a float instead of an > integer.
It's isn't really new; os.stat_float_times was introduced in Python 2.3. What changed in 2.5 is that it is now true. See http://docs.python.org/whatsnew/modules.html > a) Why the difference between machines? You really have to delve into OSX to answer this question. Several reasons are possible: - there is a change in the operating system implementations - you are using different Python versions - you are using different file systems > b) Why do most files on this machine have ".0", while some (generally > those I created myself using Python 2.5, I think) don't? Hard to tell. Maybe the software that created those files explicitly set a time stamp on them, and failed to use the API that supports subsecond resolution in setting those time stamps. > I understand how the results can be different: the os.stat() function > returns a posix.stat_result object, which gives back an integer value > for the mtime if you call __str__ or __repr__, or if you iterate on it; > and a float if you get the st_mtime attribute. But I would consider it a > bug that the results are different: a float should be returned in either > case. That's for backwards compatibility: You shouldn't use the tuple interface anymore, but use st_mtime for new code. This will always be a float. OTOH, the tuple interface will continue to return integers forever (or until the tuple interface is removed in Python 3000), as old applications will break. This breakage isn't theoretical: when I introduced float into st_mtime, I first made the tuple be float also, and it broke several applications within a week (even though that code was just in the CVS trunk, and not released yet). Regards, Martin -- http://mail.python.org/mailman/listinfo/python-list