Problems wth os.stat().st_mtime on Mac

["Martin v. Löwis"]

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