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

Victor Stinner victor.stinner at gmail.com
Thu Apr 5 01:28:18 CEST 2012

> 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.

More details why it's hard to define such function and why I dropped
it from the PEP.

If someone wants to propose again such function ("monotonic or
fallback to system" clock), two issues should be solved:

 - name of the function
 - description of the function

At least, "monotonic" and "steady" names are not acceptable names for
such function, even if the function has an optional "strict=False" or
"fallback=True" parameter. By the way, someone complained that having
a boolean parameter requires to create a new function if you want to
call it without an argument (use a lambda function, functools.partial,
or anything else). Example:

get_time = lambda: try_monotonic(fallback=True)
t = get_time()

The description should give the least guarantees.

If the function doesn't promise anything (or only a few weak
properties), it is harder to decide which clock do you need for your
use case: time.clock(), time.time(), time.monotonic(), time.<name of
the monotonic-of-fallback function>, ...


More information about the Python-Dev mailing list