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
> datetime.datetime.now().
> 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()
while event_not_occurred():
if time.time() - start >= timeout:
raise TimeOutException
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()
while event_not_occurred():
now = time.time()
if now < start:
# time went backwards, so restart the countdown
start = now
if now - start >= timeout:
raise TimeOutException
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).
Raymond
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
