On Sat, Mar 24, 2012 at 00:36, Victor Stinner wrote:

...

This seems like it should have been a PEP, or maybe should become a PEP.

I replaced time.wallclock() by time.steady(strict=False) and time.monotonic() by time.steady(strict=True). This change solved the naming issue of time.wallclock(), but it was a bad idea to merge monotonic() feature into time.steady(). It looks like everybody agrees, am I wrong?

Yes. As mentioned time.steady(i_mean_it=True) or time.steady(no_not_really=True) doesn't make any sense. Merging the methods may very well make sense, but it should then return a best case and have no flags. I think, as it has been hard to reach an agreement on this that the proposal to only make "stupid" functions that expose the system API's are the correct thing to do at the moment.

- time.time(): realtime, can be adjusted by the system administrator (manually) or automatically by NTP

Sure.

- time.clock(): monotonic clock on Windows, CPU time on UNIX

This is for historical reasons, right, because this is what it is now? Would there be a problem in making time.clock() monotonic on Unix as well, if it exists?

- time.monotonic(): monotonic clock, its speed may or may not be adjusted by NTP but it only goes forward, may raise an OSError if the OS has no monotonic clock, time.monotonic() will just not exist.

Works for me,

- time.steady(): monotonic clock or the realtime clock, depending on what is available on the platform (use monotonic in priority). may be adjusted by NTP or the system administrator, may go backward.

So it's time.may_or_may_not_be_steady() I don't mind the function, but the name should not be steady(). It's implementation is also so trivial that those who want a monotonic if it exists, but a normal clock otherwise, can simply just do

try:  return time.monotonic() except (NotImplementError, OSError):  return time.time()

themselves. //Lennart

On Fri, Mar 23, 2012 at 18:38, Yury Selivanov 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().

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.

On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin wrote:

On Fri, Mar 23, 2012 at 18:38, Yury Selivanov 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.

...

time.steady() is something like:

try:  return time.monotonic() except (NotImplementError, OSError):  return time.time()

Is the use of weak monotonic time so wide-spread in the stdlib that we need the 'steady()' function?  If it's just two modules then it's not worth adding it.

The Python standard library is not written to be used by Python itself, but by others. The try/except is a common pattern when applications use a monotonic clock. I suppose that quite all applications use this try/except pattern. I don't see what is the use case requiring a is truly monotonic clock. Victor

Victor Stinner wrote:

...

Is steady() merely a convenience function to avoid the user having to write something like this?

steady() remembers if the last call to monotonic failed or not. The real implementation is closer to something like:

def steady(): if not steady.has_monotonic: return time.time() try: return time.monotonic() except (AttributeError, OSError): steady.has_monotonic = False return time.time() steady.has_monotonic = True

Does this mean that there are circumstances where monotonic will work for a while, but then fail? Otherwise, we would only need to check monotonic once, when the time module is first loaded, rather than every time it is called. Instead of the above: # global to the time module try: monotonic() except (NameError, OSError): steady = time else: steady = monotonic Are there failure modes where monotonic can recover? That is, it works for a while, then raises OSError, then works again on the next call. If so, steady will stop using monotonic and never try it again. Is that deliberate? -- Steven

In http://mail.python.org/pipermail/python-dev/2012-March/118024.html Steven D'Aprano wrote:

What makes this "steady", given that it can be adjusted and it can go backwards?

It is best-effort for steady, but putting "best" in the name would be an attractive nuisance.

Is steady() merely a convenience function to avoid the user having to write something like this?

try: mytimer = time.monotonic except AttributeError: mytimer = time.time

That would still be worth doing. But I think the main point is that the clock *should* be monotonic, and *should* be as precise as possible. Given that it returns seconds elapsed (since an undefined start), perhaps it should be time.seconds() or even time.counter() -jJ -- If there are still threading problems with my replies, please email me with details, so that I can try to resolve them. -jJ

...

- time.clock(): monotonic clock on Windows, CPU time on UNIX

Actually, I think that is not correct. Or at least *was* not correct in 2006.

http://bytes.com/topic/python/answers/527849-time-clock-going-backwards

Oh, I was not aware of this issue. Do you suggest to not use QueryPerformanceCounter() on Windows to implement a monotonic clock? The python-monotonic-time project uses GetTickCount64(), or GetTickCount(), on Windows. GetTickCount64() was added to Windows Seven / Server 2008. GetTickCount() overflows after 49 days. QueryPerformanceCounter() has a better resolution than GetTickCount[64](). Victor

...

Oh, I was not aware of this issue. Do you suggest to not use QueryPerformanceCounter() on Windows to implement a monotonic clock?

I do not have an opinion on the best way to implement monotonic to guarantee that it actually is monotonic.

I opened an issue: http://bugs.python.org/issue14397 Victor

...

- time.monotonic(): monotonic clock, its speed may or may not be adjusted by NTP but it only goes forward, may raise an OSError - time.steady(): monotonic clock or the realtime clock, depending on what is available on the platform (use monotonic in priority). may be adjusted by NTP or the system administrator, may go backward.

I am surprised that a clock with the name time.steady() has a looser definition than one called time.monotonic(). To my mind a steady clock is by definition monotonic but a monotonic one may or may not be steady.

Do you suggest another name? Victor