On Thu, Mar 15, 2012 at 12:22 AM, Guido van Rossum <gu...@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. _______________________________________________ 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
