[Python-Dev] PEP 418 is too divisive and confusing and should be postponed

[Victor Stinner]

> 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