[Python-Dev] PEP 418: Add monotonic clock

[Scott Dial]

On 3/26/2012 7:32 PM, Victor Stinner wrote:
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.

"""
time.steady
This clock advances at a steady rate relative to real time. It may be
adjusted.
"""

Please do not call this "steady". If the clock can be adjusted, then it
is not "steady" by any acceptable definition. I cannot fathom the
utility of this function other than as a function that provides an
automatic fallback from "time.monotonic()". More importantly: this
definition of "steady" is in conflict with the C++0x definition of
"steady" that is where you sourced this named from![1]

"""
time.steady(strict=False) falls back to another clock if no monotonic
clock is not available or does not work, but it does never fail.
"""

As I say above, that is so far away from what "steady" implies that this
is a misnomer. What you are describing is a best-effort clock, which
sounds a lot more like the C++0x "high resolution" clock.

"""
time.steady(strict=True) raises OSError if monotonic clock fails or
NotImplementedError if the system does not provide a monotonic clock
"""

What is the utility of "strict=True"? If I wanted that mode of
operation, then why would I not just try to use "time.monotonic()"
directly? At worst, it generates an "AttributeError" (although that is
not clear from your PEP). What is the use case for "strict=True" that is
not covered by your "time.monotonic()"?

If you want to define new clocks, then I wish you would use the same
definitions that C++0x is using. That is:

  system_clock = wall clock time
  monotonic_clock = always goes forward but can be adjusted
  steady_clock = always goes forward and cannot be adjusted
  high_resolution_clock = steady_clock || system_clock

Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition. As well, certain
kinds of scheduling/timeouts would be better implemented with the C++0x
definition for "steady" rather than the "monotonic" one and vice-versa.

Rather, it seems you have a particular use-case in mind and have settled
on calling that a "steady" clock despite how it belies its name.

[1]
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady

"""
Objects of class steady_clock represent clocks for which values of
time_point advance at a steady rate relative to real time. That is, the
clock may not be adjusted.
"""

-- 
Scott Dial
scott at scottdial.com