Martin v. Löwis wrote:
> 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
Thanks, I wasn't aware of os.stat_float_times. This helps me a lot,
since I can turn off the floating point times in places until
incompatible code can be fixed.
>>> 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
Possible, I guess, although I don't know how to find out and there's
likely nothing I could do about it even if I did.
> - you are using different Python versions
Python 2.5 on both.
> - you are using different file systems
This is the first thing I thought of, but all of the drives are
formatted using "Mac OS Extended (Journalled)", which I assumed meant
they are using the same file system.
>>> 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
<snip>
OK, thanks for the explanation.
Mike
