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

[Glyph]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120323/2df10bb7/attachment-0001.html>