RetroSearch Browse

Fri Mar 23 17:55:17 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-March/117998.html

> I merged the two functions into one function: time.steady(strict=False).
>
> time.steady() should be monotonic most of the time, but may use a fallback.
>
> time.steady(strict=True) fails with OSError or NotImplementedError if
> reading the monotonic clock failed or if no monotonic clock is available.

If someone wants time.steady(strict=False), then why don't they just
continue to use time.time()?

I want time.steady(strict=True), and I'm glad you're providing it and
I'm willing to use it this way, although it is slightly annoying
because "time.steady(strict=True)" really means
"time.steady(i_really_mean_it=True)". Else, I would have used
"time.time()".

I am aware of a large number of use cases for a steady clock (event
scheduling, profiling, timeouts), and a large number of uses cases for
a "NTP-respecting wall clock" clock (calendaring, displaying to a
user, timestamping). I'm not aware of any use case for "steady if
implemented, else wall-clock", and it sounds like a mistake to me.

Regards,

Zooko

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117998.html below:

[Python-Dev] Drop the new time.wallclock() function?