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 -- http://mail.python.org/mailman/listinfo/python-list
