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

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