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. On Mar 20, 2012 2:56 PM, "Steven D'Aprano" <st...@pearwood.info> wrote:
> On Mon, Mar 19, 2012 at 01:35:49PM +0100, Victor Stinner wrote: > > > Said differently: time.steady(strict=True) is always monotonic (*), > > whereas time.steady() may or may not be monotonic, depending on what > > is avaiable. > > > > time.steady() is a best-effort steady clock. > > > > (*) time.steady(strict=True) relies on the OS monotonic clock. If the > > OS provides a "not really monotonic" clock, Python cannot do better. > > I don't think that is true. Surely Python can guarantee that the clock > will never go backwards by caching the last value. A sketch of an > implementation: > > def monotonic(_last=[None]): > t = system_clock() # best effort, but sometimes goes backwards > if _last[0] is not None: > t = max(t, _last[0]) > _last[0] = t > return t > > Overhead if done in Python may be excessive, in which case do it in C. > > Unless I've missed something, that guarantees monotonicity -- it may not > advance from one call to the next, but it will never go backwards. > > There's probably even a cleverer implementation that will not repeat the > same value more than twice in a row. I leave that as an exercise :) > > As far as I can tell, "steady" is a misnomer. We can't guarantee that > the timer will tick at a steady rate. That will depend on the quality of > the hardware clock. > > > -- > Steven > > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com >
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
