[Python-Dev] an alternative to embedding policy in PEP 418
v+python at g.nevcal.com
Mon Apr 2 19:44:35 CEST 2012
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:
myTime = os.monotonous
myTime = os.evenhigherres
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-Dev