On Tue, 20 Mar 2012 04:43:44 -0400, Glyph <[email protected]> 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
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
