On Fri, Apr 27, 2012 at 5:50 PM, Steven D'Aprano <st...@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)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
