[Python-Dev] [RFC] PEP 418: Add monotonic time, performance counter and process time functions

Guido van Rossum guido at python.org
Sat Apr 28 05:40:28 CEST 2012


On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano <steve at pearwood.info> wrote:
> Some issues with the PEP 418:
>
>
> 1) time.clock is deprecated, but also supported by get_clock_info. Why
> bother supporting it if you don't want people to use it?

I see the deprecation of clock() as mostly symbolic -- it's used way
too much to do anything about it (as the PEP acknowledges). So I think
it's reasonable we should return info about it.

> 2) get_clock_info returns a dict. Why not a namedtuple?

Future flexibility. And there's no need for it to be a *tuple*.

> 3) The dict returned by get_clock_info includes an optional key,
> "is_adjusted". Why is it optional?

I wondered that myself, but I suspect it means "we don't know".

> 4) The section on mach_absolute_time states:
>
>   According to the documentation (Technical Q&A QA1398),
> mach_timebase_info()
>   is always equal to one and never fails, even if the function may fail
>   according to its prototype.
>
> I've read the linked technical note and I can't see anything about it always
> being equal to one. I don't think your description is accurate.

Ok, you & Victor will have to figure that one out.

> 5) In the glossary, you mark some terms in angle brackets <> but there is no
> definition for them:
>
>  <nanosecond>
>  <strictly monotonic>
>  <clock monotonic> (which I think should be <monotonic clock> instead)
>
>
> 6) A stylistic suggestion: the glossary entries for Accuracy and Precision
> should each say "Contrast <the other>" and link to the Wikipedia article.
>
>
> 7) There is a mismatch in tenses between "Adjusted" and "Resetting" in the
> glossary. Suggest something like this instead:
>
>    Adjusted: Reset to the correct time. This may be done either
>    with a <Step> or by <Slewing>.
>
>
> 8) The glossary defines steady as high stability and "relatively high
> accuracy
>   and precision". But surely that is not correct -- a clock that ticks every
>   once per second (low precision) is still steady.
>
>
> 9) The perf_counter pseudocode seems a bit unusual (unPythonic?) to me.
> Rather than checking flags at call-time, could you not use different
> function definitions at compile time?
>
>
> 10) The "Alternatives" section should list arguments made for and against
> the alternative APIs, not just list them.
>
>
> Thanks for your excellent work Victor!

Surely those are all very minor quibbles. I have one myself: at some
point it says:

    On Linux, it is possible to use time.clock_gettime(CLOCK_THREAD_CPUTIME_ID).

But the PEP doesn't define a function by that name. Is it an editing
glitch? (Some of the pseudo code also uses this.)

-- 
--Guido van Rossum (python.org/~guido)


More information about the Python-Dev mailing list