[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Victor Stinner victor.stinner at gmail.com
Tue Mar 27 19:45:24 CEST 2012

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?

I mentioned the strict=True API in the PEP just to list all propositions, but the PEP only proposes time.monotonic() and time.try_monotonic(), no the flags API.

At worst, it generates an "AttributeError" (although that is not clear from your PEP).

I tried to mention when a function is always available or not always available. Is it better in the last version of the PEP?

 systemclock = wall clock time  monotonicclock = always goes forward but can be adjusted  steadyclock = always goes forward and cannot be adjusted  highresolutionclock = steadyclock || systemclock

I tried to follow these names in the PEP. I don't propose steady_clock because I don't see exactly which clocks would be used to implement it, nor if we need to provide monotonic and steady clocks. What do you think?

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.

I added a time.hires() clock to the PEP for the benchmarking/profiling use case. This function is not always available and so a program has to fallback manually to another clock. I don't think that it is an issue: Python programs already have to choose between time.clock() and time.time() depending on the OS (e.g. timeit module and pybench program).

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.

Sorry, I don't understand. Which kind of scheduling/timeouts?

The PEP is still a draft (work-in-progress).

Victor

More information about the Python-Dev mailing list