[Python-Dev] cpython: Issue #10278: Add an optional strict argument to time.steady(), False by default (original) (raw)

Matt Joiner anacrolix at gmail.com
Tue Mar 20 08:33:51 CET 2012


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" <steve at 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 = systemclock() # 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 at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20120320/08533aa7/attachment.html>



More information about the Python-Dev mailing list