[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

Stephen J. Turnbull stephen at xemacs.org
Sat Apr 7 10:12:30 CEST 2012

On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner
<victor.stinner at gmail.com> wrote:

> On Linux, I now prefer
> (monotonic and steady as defined by C++) *because* its frequency is
> adjusted.

I don't think that's a reason that should be considered.  There just
doesn't seem to be a single best clock, nor do clocks of similar
character seem to be easy to find across platforms.  So the reasons
I'd like to see are of the form "we should provide CLOCK_MONOTONIC on
Linux as one of our small selection of recommended clocks *because*
the frequency adjustment makes it *most* useful in use-cases A and B,
and it's a *reasonable* choice in use-case C *but* we need to document
that it's a terrible choice for use-case D."

Why do I ask for this kind of argument?  Because there are only a few
people (you, Glyph, Zooko) who seem to have studied clocks closely
enough to be able to evaluate the technical issues involved in "*this*
clock is good/mediocre/unusable in *that* use case."  I'm happy to
leave such judgments up to you guys.  What the rest of us can
contribute is (a) use cases to consider and (b) our opinions on the
relative importance of various use cases in whether we should
recommend a particular clock (ie, provide a named API in the stdlib
for it).

More information about the Python-Dev mailing list