[Python-Dev] Rename time.steady(strict=True) to time.monotonic()?

[Stephen J. Turnbull]

On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin <brian at python.org> wrote:
> On Fri, Mar 23, 2012 at 18:38, Yury Selivanov <yselivanov.ml at gmail.com> wrote:
>> On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
>>> This seems like it should have been a PEP, or maybe should become a PEP.
>>
>> Why?  AFAIK Victor just proposes to add two new functions: monotonic() and
>> steady().

Need for PEPs is not determined by volume of content, but by
amount of controversy and lack of clarity.

Isn't it obvious that there's quite a bit of disagreement about the
definitions of "monotonic" and "steady", and about whether these
functions should be what they say they are or "best effort", and
so on?

+1 for a PEP.

> We just previously had "Drop time.monotonic() function, rename
> time.wallclock() to time.steady()" checked in a few weeks ago, and now
> we're renaming a variation on time.steady to time.monotonic? What's
> the next move?
>
> I'm not paying close attention here but there's a lot of movement
> going on. Figuring out the API before we get too deep is probably a
> good idea.

I have been following the thread but don't have the technical
knowledge to be sure what's going on.

What I have decided is that I won't be using any function named
time.steady() or time.monotonic() because neither one seems
likely to guarantee the property it's named for, and by the time I
have a use case (I don't have one now, I'm just an habitual lurker)
I'll have forgotten the conclusion of this thread, but not the deep
feelings of FUD.

To get me on board (not that there's any particular reason you
should care, but just in case), you're going to need to respect
EIBTI.  By that I mean that a monotonic clock is monotonic,
and if not available at instantiation, an Exception will be
raised.  Similarly for a steady clock.  There is no such thing
as "best effort" here for clocks with these names.

The default clock should be best effort.  If that is for some
reason "expensive", then there should be a
"time.windup_clock()" to provide an unreliable resource-
conserving clock.

FWIW, I understand that

(1) A monotonic clock is one that never goes backwards.  If
precision allows, it should always go forwards (ie, repeated
calls should always produce strictly larger time values).

(2) A steady clock is strictly monotonic, and when a discrepancy
against "true time" is detected (however that might happen), it
slews its visible clock until the discrepancy is eliminated, so that
one clock second  always means something "close" to one second.