[Python-Dev] PEP 418 is too divisive and confusing and should be postponed (original) (raw)

Steven D'Aprano steve at pearwood.info
Fri Apr 6 04:23:07 CEST 2012

Greg Ewing wrote:

Cameron Simpson wrote:

A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent polls of the clock. On its own it says nothing about steadiness or correlation with real world time. No, no, no. This is the strict mathematical meaning of the word "monotonic", but the way it's used in relation to OS clocks, it seems to mean rather more than that. A clock whose only guarantee is that it never goes backwards is next to useless. For things like benchmarks and timeouts, the important thing about a clock that it keeps going forward

That would be a strictly monotonic clock, as opposed to merely monotonic.

And yes, a merely monotonic clock could just return a constant value, forever:

9, 9, 9, 9, 9, ...

and yes, such a thing would be useless.

Various people have suggested caching the last value of time() and re-using it if the new value is in the past. This will give a monotonic clock, but since it can give constant timestamps for an indefinite period, it's usefulness is limited.

I earlier put forward an alternate implementation which gives no more than one such constant tick in a row. If you know the hardware resolution of the clock, you can even avoid that single constant tick by always advancing the timestamp by that minimum resolution:

_prev = _prev_raw = 0 _res = 1e-9 # nanosecond resolution def monotonic(): global _prev, _prev_raw raw = time() delta = max(_res, raw - _prev_raw) _prev_raw = raw _prev += delta return _prev

Even if time() jumps backwards, or stays constant, monotonic() here will be strictly monotonic.

-- Steven

More information about the Python-Dev mailing list