[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)
raymond.hettinger at gmail.com
Sun Apr 8 01:36:11 CEST 2012
On Apr 7, 2012, at 3:08 AM, Paul Moore wrote:
> 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
> Event scheduler, timeout: time.monotonic().
> Benchmark, profiling: time.clock() on Windows, time.monotonic(), or
> fallback to time.time()
ISTM, an event scheduler should use time.time().
If I schedule an event at 9:30am exactly, I really
want my system time to be one that is used.
Stock traders, for example, need to initiate event based
on scheduled times (i.e. the market opening and closing times).
With respect to benchmarking, the important attribute of time keeping
is that the start and end times be computed from the same offset.
For that purpose, I would want a clock that wasn't subject to adjustment at all,
or if it did adjust, do so in a way that doesn't hide the fact (i.e. spreading-out
the adjustment over a number of ticks or freezing time until a negative
adjustment had caught-up).
Then, there are timeouts, a common use-case where I'm not clear on the
relative merits of the different clocks. Which is the recommended clock
for code like this?
start = time.time()
if time.time() - start >= timeout:
Ideally, the clock used here shouldn't get adjusted during the timing.
Failing that, the system time (plain old time.time()) seems like a reasonable
choice (I'm not used to seeing the system time just around at an irregular pace).
If time gets set backwards, it is possible to add code to defend against that as long as
the clock doesn't try to hide that time went backwards:
start = time.time()
now = time.time()
if now < start:
# time went backwards, so restart the countdown
start = now
if now - start >= timeout:
If the new clocks go in (or rather stay in), there should be some clear recommendations
about which ones to use for various use cases. Those recommendations need to be
explained (i.e. under what circumstance would timeout code be better if one abandoned
time.time() in favor of one of the new clocks).
I ask this because adding multiple clocks WILL cause some confusion.
There will be cases where different tools use different clocks, resulting in unexpected interactions.
Victor is proposing that almost every use of time.time() in the standard library be replaced by
monotonic, but I'm at a loss to explain whether the code would actually be better off
or to explain in what circumstances the new code would behave differently in any observable way.
AFAICT, there has never been a reported bug in sched or Queue because they used time.time(),
so I'm reluctant to have those changed without very clear understanding of how the code would
be better (i.e. what negative outcome would be avoided with time.monotonic or somesuch).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev