[Python-Dev] PEP 418: Add monotonic clock

[Nick Coghlan]

On Tue, Mar 27, 2012 at 7:03 PM, Lennart Regebro <regebro at gmail.com> wrote:
> But a time.steady() that tries to get a "best case" doesn't make sense
> at this time, as apparently nobody knows what a best case is, or what
> it should be called, except that it should apparently not be called
> steady(). Since monotonic() raises an error if there is no monotonic
> clock available, implementing your own fallback is trivial in any
> case.

+1 from me to Lennart's suggestion of mostly just exposing
time.monotonic() without trying to get too clever. Applications that
need a truly precise time source should *never* be reading it from the
host OS (one fairly good solution can be to read your time directly
from an attached GPS device).

However, I think Victor's right to point out that the *standard
library* needs to have a fallback to maintain backwards compatibility
if time.monotonic() isn't available, and it seems silly to implement
the same fallback logic in every module where we manipulate timeouts.
As I concur with others that time.steady() is a thoroughly misleading
name for this concept, I suggest we encapsulate the "time.monotic if
available, time.time otherwise" handling as a "time.try_monotic()"
function.

That's simple clear and explicit: try_monotic() tries to use the
monotic clock if it can, but falls back to time.time() rather than
failing entirely if no monotonic clock is available. This is essential
for backwards compatibility when migrating any current use of
time.time() over to time.monotic(). Yes the monotonic clock is
*better* for many use cases (including timeouts), but you'll usually
be OK with the non-monotonic clock, too (particularly if that's what
you were using anyway in earlier versions). After all, we've survived
this long using time.time() for our timeout calculations, and bugs
associated with clock adjustments are a rather rare occurrence.

Third party libraries that need to support earlier Python versions can
then implementation their own fallback logic (since they couldn't rely
on time.try_monotonic being available either).

The 3.3 time module would then be left with three interfaces:

time.time() # Highest resolution timer available
time.monotonic() # I'm not yet convinced we need the "raw" parameter
but don't much mind either way
time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia