[Python-Dev] PEP 418: Add monotonic clock

Scott Dial scott+python-dev at scottdial.com
Tue Mar 27 02:23:12 CEST 2012

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.

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

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.


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

More information about the Python-Dev mailing list