[Python-Dev] an alternative to embedding policy in PEP 418

Glenn Linderman 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:

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120402/70587611/attachment-0001.html>

More information about the Python-Dev mailing list