On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum <guido at python.org> wrote: > I have a totally different observation. Presumably the primary use > case for these timers is to measure real time intervals for the > purpose of profiling various operations. For this purpose we want them > to be as "steady" as possible: tick at a constant rate, don't jump > forward or backward. (And they shouldn't invoke the concept of "CPU" > time -- we already have time.clock() for that, besides it's often > wrong, e.g. you might be measuring some sort of I/O performance.) If > this means that a second as measured by time.time() is sometimes not > the same as a second measured by this timer (due to time.time() > occasionally jumping due to clock adjustments), that's fine with me. > If this means it's unreliable inside a VM, well, it seems that's a > property of the underlying OS timer, and there's not much we can do > about it except letting a knowledgeable user override the timer user. > As for names, I like Jeffrey's idea of having "steady" in the name. In that case I'd suggest either time.hardware(strict=True), or time.steady(strict=True), since the only timers exposed natively that are both high resolution and steady are on the hardware. A warning about CPU affinity is also still wise methinks.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4