[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)

[Paul Moore]

On 7 April 2012 09:12, Stephen J. Turnbull <stephen at xemacs.org> wrote:
>
> 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."


>From the PEP:

"""
Use cases:

Display the current time to a human (e.g. display a calendar or draw a
wall clock): use system clock, i.e. time.time() or
datetime.datetime.now().
Event scheduler, timeout: time.monotonic().
Benchmark, profiling: time.clock() on Windows, time.monotonic(), or
fallback to time.time()

Functions

To fulfill the use cases, the functions' properties are:

time.time(): system clock, "wall clock".
time.monotonic(): monotonic clock
time.get_clock_info(name): get information on the specified time function
"""

That broadly covers it, I'd say. There are 2 main exceptions I see:
(1) your suggestion of "explain why clock X is a terrible choice for
use case Y" isn't there, although I'm not sure how important that is,
and (2) there's no really good cross-platform option given for
benchmarking/profiling (time.clock() is fine on Windows, but it gives
CPU time on Unix - is that acceptable?)

Also, Victor - you missed time.clock() from "Functions". Was that
deliberate because it's sometimes CPU time? Maybe it should be added
for clarity?

Paul.