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

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 getclockinfo. 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) getclockinfo 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 getclockinfo includes an optional key, "isadjusted". Why is it optional?

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

4) The section on machabsolutetime states:

According to the documentation (Technical Q&A QA1398), machtimebaseinfo() 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:

      (which I think should be instead)

6) A stylistic suggestion: the glossary entries for Accuracy and Precision should each say "Contrast " 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 or by . 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 perfcounter 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