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

Stephen J. Turnbull stephen at xemacs.org
Sat Mar 24 16:39:38 CET 2012

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.

More information about the Python-Dev mailing list