[Python-Dev] Use QueryPerformanceCounter() for time.monotonic() and/or time.highres()? (original) (raw)

Victor Stinner victor.stinner at gmail.com
Sat Mar 31 03:24:53 CEST 2012

There seem to be a few competing features for clocks that people want:

 - monotonic - never going backward at all  - high resolution

These features look to be exclusive on Windows. On other platforms, it looks like monotonic clocks are always the most accurate clocks. So I don't think that we need to be able to combine these two "flags".

 - no steps

You mean "not adjusted by NTP"? Except CLOCK_MONOTONIC on Linux, no monotonic clock is adjusted by NTP. On Linux, there is CLOCK_MONOTONIC_RAW, but it is only available on recent Linux kernel (2.6.28).

Do you think that it is important to be able to refuse a monotonic clock adjusted by NTP? What would be the use case of such truly steady clock?

--

The PEP 418 tries to expose various monotonic clocks in Python with a simple API. If we fail to agree how to expose these clocks, e.g. because there are major differences between these clocks, another solution is to only expose low-level function. This is already what we do with the os module, and there is the shutil module (and others) for a higher level API. I already added new "low-level" functions to the time module: time.clock_gettime() and time.clock_getres().

Of course you can provide some convenient-with-fallback function that will let people do this in one hit without the need for "T", but it should not be the base facility offered. The base should let people request their feature set and inspect what is supplied.

The purpose of such function is to fix programs written with Python < 3.3 and using time.time() whereas a monotonic would be the right clock (e.g. implement a timeout).

Another concern is to write portable code. Python should help developers to write portable code, and time.monotonic(fallback=False) is not always available (and may fail).

Victor

More information about the Python-Dev mailing list