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

Matt Joiner anacrolix at gmail.com
Wed Mar 14 18:08:39 CET 2012

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.

More information about the Python-Dev mailing list