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

Russell E. Owen rowen at uw.edu
Thu Mar 15 20:22:03 CET 2012

In article <EFE3877620384242A686D52278B7CCD3362609 at RKV-IT-EXCH104.ccp.ad.local>, Kristján Valur Jónsson <kristjan at ccpgames.com> wrote:

What does "jumping forward" mean? That's what happens with every clock at every time quantum. The only effect here is that this clock will be slightly noisy, i.e. its precision becomes worse. On average it is still correct. Look at the use cases for this function 1) to enable timeouts for certaing operations, like acquiring locks: Jumping backwards is bad, because that may cause infinite wait time. But jumping forwards is ok, it may just mean that your lock times out a bit early 2) performance measurements: If you are running on a platform with a broken runtime clock, you are not likely to be running performance measurements.

Really, I urge you to skip the "strict" keyword. It just adds confusion. Instead, lets just give the best monotonic clock we can do which doesn"t move backwards. Let's just provide a "practical" real time clock with high resolution that is appropriate for providing timeout functionality and so won't jump backwards for the next 20 years. Let's simply point out to people that it may not be appropriate for high precision timings on old and obsolete hardware and be done with it.

I agree. I prefer the name time.monotonic with no flags. It will suit most use cases. I think supplying truly steady time is a low level hardware function (e.g. buy a GPS timer card) with a driver.

-- Russell

More information about the Python-Dev mailing list