<div dir="ltr">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.<div><br></div><div>-Ben</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 16, 2017 at 9:50 AM, Victor Stinner <span dir="ltr"><<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I read again the discussions on python-ideas and noticed that I forgot<br>
to mention the "time_ns module" idea. I also added a section to give<br>
concrete examples of the precision loss.<br>
<br>
<a href="https://github.com/python/peps/commit/a4828def403913dbae7452b4f9b9d62a0c83a278" rel="noreferrer" target="_blank">https://github.com/python/<wbr>peps/commit/<wbr>a4828def403913dbae7452b4f9b9d6<wbr>2a0c83a278</a><br>
<br>
Issues caused by precision loss<br>
------------------------------<wbr>-<br>
<br>
Example 1: measure time delta<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
<br>
A server is running for longer than 104 days. A clock is read before<br>
and after running a function to measure its performance. This benchmark<br>
lose precision only because the float type used by clocks, not because<br>
of the clock resolution.<br>
<br>
On Python microbenchmarks, it is common to see function calls taking<br>
less than 100 ns. A difference of a single nanosecond becomes<br>
significant.<br>
<br>
Example 2: compare time with different resolution<br>
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<wbr>^^^^^^^^^^^^^^^^^^^<br>
<br>
Two programs "A" and "B" are runing on the same system, so use the system<br>
block. The program A reads the system clock with nanosecond resolution<br>
and writes the timestamp with nanosecond resolution. The program B reads<br>
the timestamp with nanosecond resolution, but compares it to the system<br>
clock read with a worse resolution. To simplify the example, let's say<br>
that it reads the clock with second resolution. If that case, there is a<br>
window of 1 second while the program B can see the timestamp written by A<br>
as "in the future".<br>
<br>
Nowadays, more and more databases and filesystems support storing time<br>
with nanosecond resolution.<br>
<br>
.. note::<br>
This issue was already fixed for file modification time by adding the<br>
``st_mtime_ns`` field to the ``os.stat()`` result, and by accepting<br>
nanoseconds in ``os.utime()``. This PEP proposes to generalize the<br>
fix.<br>
<br>
(...)<br>
<br>
Modify time.time() result type<br>
------------------------------<br>
<br>
It was proposed to modify ``time.time()`` to return a different float<br>
type with better precision.<br>
<br>
The PEP 410 proposed to use ``decimal.Decimal`` which already exists and<br>
supports arbitray precision, but it was rejected. Apart<br>
<span class="">``decimal.Decimal``, no portable ``float`` type with better precision is<br>
currently available in Python.<br>
<br>
Changing the builtin Python ``float`` type is out of the scope of this<br>
PEP.<br>
<br>
</span>Moreover, changing existing functions to return a new type introduces a<br>
risk of breaking the backward compatibility even the new type is<br>
designed carefully.<br>
<br>
(...)<br>
<br>
New time_ns module<br>
------------------<br>
<br>
Add a new ``time_ns`` module which contains the five new functions:<br>
<br>
* ``time_ns.clock_gettime(clock_<wbr>id)``<br>
* ``time_ns.clock_settime(clock_<wbr>id, time: int)``<br>
* ``time_ns.perf_counter()``<br>
* ``time_ns.monotonic()``<br>
* ``time_ns.time()``<br>
<br>
The first question is if the ``time_ns`` should expose exactly the same<br>
API (constants, functions, etc.) than the ``time`` module. It can be<br>
painful to maintain two flavors of the ``time`` module. How users use<br>
suppose to make a choice between these two modules?<br>
<br>
If tomorrow, other nanosecond variant are needed in the ``os`` module,<br>
will we have to add a new ``os_ns`` module as well? There are functions<br>
related to time in many modules: ``time``, ``os``, ``signal``,<br>
``resource``, ``select``, etc.<br>
<br>
Another idea is to add a ``time.ns`` submodule or a nested-namespace to<br>
get the ``time.ns.time()`` syntax.<br>
<span class="HOEnZb"><font color="#888888"><br>
Victor<br>
</font></span><div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/benhoyt%40gmail.com" rel="noreferrer" target="_blank">https://mail.python.org/<wbr>mailman/options/python-dev/<wbr>benhoyt%40gmail.com</a><br>
</div></div></blockquote></div><br></div>