[Python-Dev] an alternative to embedding policy in PEP 418 (was: PEP 418: Add monotonic clock)

[Victor Stinner]

> I've just finished sketching out a skeleton here:
>
>  https://bitbucket.org/cameron_simpson/css/src/fb476fcdcfce/lib/python/cs/clockutils.py

get_clock() returns None if no clock has the requested flags, whereas
I expected an exception (LookupError or NotImplementError?).

get_clock() doesn't remember if a clock works or not (if it raises an
OSError) and does not fallback to the next clock on error. See
"pseudo-codes" in the PEP 418.

The idea of flags attached to each clock is interesting, but I don't
like the need of different list of clocks. Should I use
MONTONIC_CLOCKS or HIRES_CLOCKS when I would like a monotonic and
high-resolution clock? It would be simpler to have only one global and
*private* list.

If you have only one list of clocks, how do sort the list to get
QueryPerformanceCounter when the user asks for highres and
GetTickCount when the user asks for monotonic? The "if clock.flags &
flags == flags:" test in get_clock() is maybe not enough. I suppose
that we would have the following flags for Windows functions:

QueryPerformanceCounter.flags = T_HIRES
GetTickCount.flags = T_MONOTONIC | T_STEADY

(or maybe QueryPerformanceCounter.flags = T_HIRES | T_MONOTONIC ?)

monotonic_clock() should maybe try to get a clock using the following
list of conditions:
 - T_MONOTONIC | T_STEADY
 - T_MONOTONIC | T_HIGHRES
 - T_MONOTONIC

The T_HIGHRES flag in unclear, even in the PEP. According to the PEP,
any monotonic clock is considered as a "high-resolution" clock. Do you
agree? So we would have:

GetTickCount.flags = T_MONOTONIC | T_STEADY | T_HIGHRES

Even if GetTickCount has only an accuracy of 15 ms :-/

Can list please give the list of flags of each clocks listed in the
PEP? Only clocks used for time.time, time.monotonic and time.highres
(not process and thread clocks nor QueryUnbiasedInterruptTime).

>      # get a clock object - often a singleton under the hood
>      T = get_clock(T_MONOTONIC|T_HIRES) or get_clock(T_STEADY|T_HIRES)
>      # what kind of clock did I get?
>      print T.flags
>      # get the current time
>      now = T.now

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.

> This removes policy from the library functions and makes it both simple
> and obvious in the user's calling code, and also makes it possible for
> the user to inspect the clock and find out what quality/flavour of clock
> they got.

I'm not sure that users understand correctly differences between all
these clocks and are able to use your API correctly. How should I
combinese these 3 flags (T_HIRES, T_MONOTONIC and T_STEADY)? Can I use
any combinaison?

Which flags are "portable"? Or should I always use an explicit
fallback to ensure getting a clock on any platform?

Could you please update your code according to my remarks? I will try
to integrate it into the PEP. A PEP should list all alternatives!

Victor