On Mar 23, 2012, at 12:55 PM, Zooko Wilcox-O'Hearn wrote:
>> 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.
I think I've lost the thread of this discussion. Is that really what
"strict=False" was supposed to mean?
I am aware of use-cases which want to respect slew, but reject steps. The
local clock might not be all that reliable, and slew actually keeps it closer
to "real" time. My understanding was that strict=True was something like
CLOCK_MONOTONIC_RAW and strict=False was just CLOCK_MONOTONIC.
I am increasingly thinking that the first order of business here should be to
expose the platform-specific mechanisms directly, then try to come up with a
unifying abstraction in the time module later. It's hard enough to understand
the substantially dense verbiage around all of these different timers on their
respective platforms; understanding which one exactly Python is swaddling up in
a portability layer seems bound to generate confusion. Not to mention that you
run into awesome little edge cases like this:
https://github.com/ThomasHabets/monotonic_clock/blob/master/src/monotonic_win32.c#L62
which means sometimes you really really need to know exactly which clock is
getting used, if you want to make it work right (unless Python is going to ship
with all of these workarounds on day 1).
(I still object to the "time.steady" naming, because this is what people in the
make-believe land of C++ call it. The people who live in the real world of C
and POSIX all refer to it as "monotonic". And even the C++ purists slip up
sometimes, c.f. <http://en.cppreference.com/w/cpp/chrono/steady_clock>: "Class
std::chrono::steady_clock represents a monotonic clock.")
If there really are some applications for which the desired behavior is
'monotonic clock, but if you can't get one, nevermind, wallclock is good
enough', it strikes me that this should be as explicit as possible, it should
not be the default, and if
try:
value = time.steady()
except OhWowYourComputerReallyHasProblems:
value = time.time()
is generally considered too onerous, it should be spelled
time.steady(fallback=time.time).
-glyph_______________________________________________
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
