> I failed to propose a consistent and clear API because I (and Guido!) wanted > to fallback to the system clock. Falling back to the system clock is a > problem when you have to define the function in the documentation or if you > don't want to use the system clock (but do something else) if no monotonic > clock is available.
Well, it was not only Guido and me. Nick Coghlan wrote: "However, I think Victor's right to point out that the *standard library* needs to have a fallback to maintain backwards compatibility if time.monotonic() isn't available, and it seems silly to implement the same fallback logic in every module where we manipulate timeouts." and "Since duplicating that logic in every module that handles timeouts would be silly, it makes sense to provide an obvious way to do it in the time module." Michael Foord wrote: "It is this always-having-to-manually-fallback-depending-on-os that I was hoping your new functionality would avoid. Is time.try_monotonic() suitable for this usecase?" The following functions / libraries fall back to the system clock if no monotonic clock is available: - QElapsedTimer class of the Qt library - g_get_monotonic_time() of the glib library - monotonic_clock library - AbsoluteTime.now (third-party Ruby library), "AbsoluteTime.monotonic?" tells if AbsoluteTime.now is monotonic Extract of the glib doc: "Otherwise, we make a best effort that probably involves returning the wall clock time (with at least microsecond accuracy, subject to the limitations of the OS kernel)." -- Only the python-monotonic-time fails with an OSError if no monotonic clock is available. System.nanoTime() of Java has few garantee: "Returns the current value of the most precise available system timer, in nanoseconds. This method can only be used to measure elapsed time and is not related to any other notion of system or wall-clock time. The value returned represents nanoseconds since some fixed but arbitrary time (perhaps in the future, so values may be negative)." I don't even know if it is monotonic, steady or has an high resolution. Note: Boost.Chrono.high_resolution_clock falls back to the system clock if no steady clock is available. (But the high-resolution clock idea was deferred, it's something different than a monotonic or steady clock.) Victor _______________________________________________ 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