On 4/2/2012 4:37 AM, Victor Stinner wrote:

The API looks much more complex than the API proposed in PEP 418 just
to get the time. You have to call a function to get a function, and
then call the function, instead of just calling a function directly.

Instead of returning an object with a now() method, I would prefer to
get directly the function getting time, and another function to get
"metadata" of the clock.

If there are more than two clocks, with different characteristics, no API is going to be both simple to use and fast to call.

If there are more than two clocks, with different characteristics, then having an API to get the right API to call to get a time seems very natural to me.

One thing I don't like about the idea of fallback being buried under some API is that the efficiency of that API on each call must be less than the efficiency of directly calling an API to get a single clock's time. For frequently called high resolution clocks, this is more burdensome than infrequently called clocks.... yet those seem to be the ones for which fallbacks are proposed, because of potential unavailability.

Having properties on each of various different clock functions is cumbersome... the user code must know about each clock, how to obtain the properties, and then how to choose one for use... And how will one be chosen for use? Under the assumption that all return some sort of timestamp and take no parameters, a local name will be assigned to the clock of interest:

if ...:
     myTime = os.monotonous
elif ...:
    myTime = os.evenhigherres
...
elif ...:
     myTime = time. time

so that myTime can be use throughout. Cameron's API hides all the names of the clocks, and instead offers to do the conditional logic for you, and the resultant API returned can be directly assigned to myTime, and the logic for choosing a clock deals only with the properties of the clock, not the names of the APIs, which is a nice abstraction. There would not even be a need to document the actual names of the APIs for each individual clock, except that probably some folks would want to directly code them, especially if they are not interested in cross-platform work.

The only thing I'm not so sure about: can the properties be described by flags? Might it not be better to have an API that allows specification of minimum resolution, in terms of fractional seconds? Perhaps other properties suffice as flags, but perhaps not resolution.