On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner <victor.stinner@gmail.com> 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 | ncoghlan@gmail.com | Brisbane, Australia