>> I prefer "steady" over "monotonic" because the steady property is what
>> users really expect from a "monotonic" clock. A monotonic but not
>> steady clock may be useless.
>
> "steady" is ambiguous IMO. It can only be "steady" in reference to
> another clock - but which one ? (real time presumab
On Sat, 14 Apr 2012 02:51:09 +0200
Victor Stinner wrote:
>
> time.monotonic() does not fallback to the system clock anymore, it is
> now always monotonic.
Then just call it "monotonic" :-)
> I prefer "steady" over "monotonic" because the steady property is what
> users really expect from a "mon
On 14 April 2012 06:41, Stephen J. Turnbull wrote:
> A clock can be accurate in measuring
> duration even though it is not accurate in measuring the point in
> time. [It's hard to see how the opposite could be true.]
Pedantic point: A clock that is stepped (say, by NTP) is precisely one
that is
On Sat, Apr 14, 2012 at 02:51, Victor Stinner wrote:
> Hi,
>
> Before posting a first draft of the PEP 418 to python-dev, I have some
> questions.
>
> == Naming: time.monotonic() or time.steady()? ==
The clock is monotonic by all reasonable definitions of monotonic (ie
they don't go backwards). T
Executive summary:
On naming, how about "CLOCK_METRONOMIC"? Also, "is_adjusted" is
better, until the API is expanded to provide "when and how much"
information about past adjustments.
On the glossary, (1) precision, accuracy, and resolution mean
different things for "points in time" and for "dur
Hi,
Before posting a first draft of the PEP 418 to python-dev, I have some
questions.
== Naming: time.monotonic() or time.steady()? ==
I like the "steady" name but different people complained that the
steady name should not be used if the function falls back to the
system clock or if the clock i
