Larry Hastings <la...@hastings.org> added the comment: 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(). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue11457> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
