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

[Cameron Simpson]

On 02Apr2012 10:44, Glenn Linderman <v+python at g.nevcal.com> wrote:
| 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.

It is, though Victor's point about offering the very easy to use API is
valid. The new code has the "flat" monotonic() et al calls as well.

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

I hadn't thought about that, but it isn't actually a big deal. The
overhead isn't zero, but in order to always use the _same_ clock to
return hires() (for example) the library has to cache the clock lookup
anyway. Current clockutils.py skeleton here:

  https://bitbucket.org/cameron_simpson/css/src/91848af8663b/lib/python/cs/clockutils.py

does so.

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

It sounds nice, but there are some difficulties.

Firstly, the (currently just 3) flags were chosen to map to the three
features sought (in various cobinations) for clocks. Once you start
requesting precision (a totally reasonable desire, BTW) you also want to
request degree of slew (since "steady" is a tunabe term) and so forth.
And what for clocks that have variable precision (I'm imaging here a
clock which really is a float, and for large times (in the far future)
can't return the sane resolution because of the size of a float.

The concern is valid though. I could imagine beefing up the clock object
metadata with .epoch (can be None!), precision (function of float width
versus clock return value epislon), epsilon (your fraction of a second
parameter). Of course, for some clocks any of these might be None.

Then the truly concerned user iterates over the available clocks
with the desired coarse flags, inspecting each closely for precision
or whatever. Easy enough to tweak get_clock() to take an optional
all_clocks=False parameter to return all matching clocks in an iterable
instead of (the first match or None). Or the user could reach directly
for one of the clock lists.

cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Craft, n.  A fool's substitute for brains.      - The Devil's Dictionary