[Python-Dev] PEP 564: Add new time functions with nanosecond resolution (original) (raw)

Ben Hoyt benhoyt at gmail.com
Mon Oct 16 11:37:37 EDT 2017

I've read the examples you wrote here, but I'm struggling to see what the real-life use cases are for this. When would you care about both very long-running servers (104 days+) and nanosecond precision? I'm not saying it could never happen, but would want to see real "experience reports" of when this is needed.

-Ben

On Mon, Oct 16, 2017 at 9:50 AM, Victor Stinner <victor.stinner at gmail.com> wrote:

I read again the discussions on python-ideas and noticed that I forgot to mention the "timens module" idea. I also added a section to give concrete examples of the precision loss.

https://github.com/python/peps/commit/a4828def403913dbae7452b4f9b9d6 2a0c83a278 Issues caused by precision loss ------------------------------- Example 1: measure time delta ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ A server is running for longer than 104 days. A clock is read before and after running a function to measure its performance. This benchmark lose precision only because the float type used by clocks, not because of the clock resolution. On Python microbenchmarks, it is common to see function calls taking less than 100 ns. A difference of a single nanosecond becomes significant. Example 2: compare time with different resolution ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Two programs "A" and "B" are runing on the same system, so use the system block. The program A reads the system clock with nanosecond resolution and writes the timestamp with nanosecond resolution. The program B reads the timestamp with nanosecond resolution, but compares it to the system clock read with a worse resolution. To simplify the example, let's say that it reads the clock with second resolution. If that case, there is a window of 1 second while the program B can see the timestamp written by A as "in the future". Nowadays, more and more databases and filesystems support storing time with nanosecond resolution. .. note:: This issue was already fixed for file modification time by adding the stmtimens field to the os.stat() result, and by accepting nanoseconds in os.utime(). This PEP proposes to generalize the fix. (...) Modify time.time() result type ------------------------------ It was proposed to modify time.time() to return a different float type with better precision. The PEP 410 proposed to use decimal.Decimal which already exists and supports arbitray precision, but it was rejected. Apart decimal.Decimal, no portable float type with better precision is currently available in Python. Changing the builtin Python float type is out of the scope of this PEP. Moreover, changing existing functions to return a new type introduces a risk of breaking the backward compatibility even the new type is designed carefully. (...) New timens module ------------------ Add a new timens module which contains the five new functions: * timens.clockgettime(clockid) * timens.clocksettime(clockid, time: int) * timens.perfcounter() * timens.monotonic() * timens.time() The first question is if the timens should expose exactly the same API (constants, functions, etc.) than the time module. It can be painful to maintain two flavors of the time module. How users use suppose to make a choice between these two modules? If tomorrow, other nanosecond variant are needed in the os module, will we have to add a new osns module as well? There are functions related to time in many modules: time, os, signal, resource, select, etc. Another idea is to add a time.ns submodule or a nested-namespace to get the time.ns.time() syntax. Victor

Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ benhoyt%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20171016/3e93819d/attachment-0001.html>

More information about the Python-Dev mailing list