Author larry
Recipients Alexander.Belopolsky, Arfrever, belopolsky, jcea, khenriksson, larry, lars.gustaebel, loewis, mark.dickinson, nadeem.vawda, r.david.murray, rosslagerwall, skrah, vstinner
Date 2011-09-11.14:50:02
SpamBayes Score 6.79053e-08
Marked as misclassified No
Message-id <1315752603.64.0.416678411165.issue11457@psf.upfronthosting.co.za>
In-reply-to
Content
Victor STINNER:
> Python is compiled using Visual Studio 2008 on Windows. Portability
> does matter on Python. If a type is not available on *all* platforms
> (including some old platforms, e.g. FreeBSD 6 or Windows XP), we
> cannot use it by default.

The quad-precision float would be highly portable, but not 100% guaranteed.  The idea is that st_mtime would be a float128 on a recent Linux, but still a double on Windows.  Python's "duck typing", combined with a judicious implementation of float128, would permit code that performed simple math on a timestamp to run unchanged.  That should be sufficient for almost all existing code that deals with these timestamps.

But there are obvious, plausible scenarios where this would break.  For example: pickling a float128 mtime on one platform and attempting to unpickle it on Windows.  I can imagine legitimate reasons why one would want to ship ctime/atime/mtime across platforms.

If that's an unacceptable level of portability, then for the proposal to remain viable we'd have to implement our own portable quad-precision floating point type.  That's a staggering amount of work, and I doubt it would happen.  But short of some quad-precision type, there's no way to preserve existing code and have it get more precise automatically.

If float128 isn't viable then the best remaining option is Decimal.  But changing st_mtime to Decimal would be an even more violent change than changing it to float was.  I propose adding the Decimal fields "ctime", "atime", and "mtime" to the named tuple returned by os.stat().
History
Date User Action Args
2011-09-11 14:50:03larrysetrecipients: + larry, loewis, jcea, mark.dickinson, belopolsky, lars.gustaebel, vstinner, nadeem.vawda, Arfrever, r.david.murray, skrah, Alexander.Belopolsky, rosslagerwall, khenriksson
2011-09-11 14:50:03larrysetmessageid: <1315752603.64.0.416678411165.issue11457@psf.upfronthosting.co.za>
2011-09-11 14:50:03larrylinkissue11457 messages
2011-09-11 14:50:02larrycreate