[Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)

[Paul Moore]

On 6 April 2012 11:12, Steven D'Aprano <steve at pearwood.info> wrote:

> Glyph Lefkowitz wrote:
>
>> On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote:
>>
>
>  2. Those who think that "monotonic clock" means a clock that never jumps,
>>> and that runs at a rate approximating the rate of real time. This is a
>>> very useful kind of clock to have! It is what C++ now calls a "steady
>>> clock". It is what all the major operating systems provide.
>>>
>>
>> All clocks run at a rate approximating the rate of real time.  That is
>> very
>> close to the definition of the word "clock" in this context.  All clocks
>> have flaws in that approximation, and really those flaws are the whole
>> point of access to distinct clock APIs.  Different applications can cope
>> with different flaws.
>>
>
> I think that this is incorrect.
>
> py> time.clock(); time.sleep(10); time.clock()
> 0.41
> 0.41
>

Blame Python's use of CPU time in clock() on Unix for that. On Windows:

>>> time.clock(); time.sleep(10); time.clock()
14.879754156329385
24.879591008462793

That''s a backward compatibility issue, though - I'd be arguing that
time.clock() is the best name for "normally the right clock for interval,
benchmark or timeout uses as long as you don't care about oddities like
suspend" otherwise. Given that this name is taken, I'd argue for
time.wallclock. I'm not familiar enough with the terminology to know what
to expect from terms like monotonic, steady, raw and the like.

Paul.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20120406/8a94b27a/attachment.html>