Problems wth os.stat().st_mtime on Mac

Michael Glassford glassfordm at hotmail.com
Mon Oct 2 16:15:26 CEST 2006


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




More information about the Python-list mailing list