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

Steven D'Aprano steve at pearwood.info
Sat Apr 28 02:50:37 CEST 2012


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?


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


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


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.


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!



-- 
Steven


More information about the Python-Dev mailing list