On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner <[email protected]> wrote: >>>> In that case, I don't think time.try_monotonic() is really needed >>>> because we can emulate "time.monotonic()" in software if the platform is >>>> deficient. >>> >>> As I wrote, I don't think that Python should workaround OS bugs. If >>> the OS monotonic clock is not monotonic, the OS should be fixed. >> >> I sympathize with this, but if the idea is that the Python stdlib should >> use time.monotonic() for scheduling, then it needs to always be >> available. Otherwise, we are not going to use it ourselves, and what >> sort of example is that to set? > > There is time.hires() if you need a monotonic clock with a fallback to > the system clock.
Completely unintuitive and unnecessary. With the GIL taking care of synchronisation issues, we can easily coerce time.time() into being a monotonic clock by the simple expedient of saving the last returned value: def _make_monotic: try: # Use underlying system monotonic clock if we can return _monotonic except NameError: _tick = time() def monotic(): _new_tick = time() if _new_tick > _tick: _tick = _new_tick return _tick monotonic = _make_monotonic() Monotonicity of the result is thus ensured, even when using time.time() as a fallback. If using the system monotonic clock to get greater precision is acceptable for an application, then forcing monotonicity shouldn't be a problem either. Regards, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia _______________________________________________ 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