[issue11457] Expose nanosecond precision from system calls

[Larry Hastings]

Larry Hastings <larry at 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 <report at bugs.python.org>
<http://bugs.python.org/issue11457>
_______________________________________