RetroSearch Browse

Tue Mar 20 13:32:10 CET 2012 · https://mail.python.org/pipermail/python-dev/2012-March/117830.html

On Tue, 20 Mar 2012 04:43:44 -0400, Glyph <glyph at twistedmatrix.com> wrote:
> 
> On Mar 20, 2012, at 3:33 AM, Matt Joiner wrote:
> 
> > I believe we should make a monotonic_time method that assures monotonicity and be done with it. Forward steadiness can not be guaranteed. No parameters.
> > 
> 
> I think this discussion has veered off a bit into the overly-theoretical.  Python cannot really "guarantee" anything here; alternately, it guarantees everything, since if you don't like what Python gives you you can always get your money back :).  It's the OS's job to guarantee things.  We can all agree that a monotonic clock of some sort is useful.
> 
> However, maybe my application wants CLOCK_MONOTONIC and maybe it wants CLOCK_MONOTONIC_RAW.  Sometimes I want GetTickCount64 and sometimes I want QueryUnbiasedInterruptTime.  While these distinctions are probably useless to most applications, they may be of interest to some, and Python really shouldn't make it unduly difficult to get at them.

Something like:

    time.steady(require_clock=None)

where require_clock can be any of BEST, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW,
GetTickCount64, QueryUnbiastedInterruptTime, etc?  Then None would mean
it is allowable to use time.time and the cache-the-last-time-returned
algorithm, and BEST would be Victor's current 'strict=True'.  And if you
require a Linux clock on Windows or vice-versa, on your own head be it :)

--David

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2012-March/117830.html below:

Add an optional strict argument to time.steady(), False by default