[Python-Dev] PEP 418: rename time.monotonic() to time.steady()?

[Cameron Simpson]

On 03Apr2012 13:26, Victor Stinner <victor.stinner at gmail.com> wrote:
| I would to rename time.monotonic() to time.steady() in the PEP 418 for
| the following reasons:
| 
|  - time.steady() may fallback to the system clock which is not
| monotonic, it's strange to have to check for
| time.get_clock_info('monotonic')['is_monotonic']
|  - time.steady() uses GetTickCount() instead of
| QueryPerformanceCounter() whereas both are monotonic, but
| QueryPerformanceCounter() is not steady
| 
| Python steady clock will be different than the C++ definition.
| 
| You may argue that time.steady() is not always steady: it may fallback
| to the system clock which is adjusted by NTP and can jump
| backward/forward with a delta greater than 1 hour.

An HOUR ?!?!?

I have to say I'm -100 on any proposal where time.monotonic() returns
non-monotonic time and likewise for time.steady() returning unsteady
time.

| In practice, there
| is only one operating system that does not provide a monotonic clock:
| GNU/Hurd.

I'd have thought practically any early UNIX falls into this category.
And any number of other niche things. (Yes I know Python doesn't run on
everything anyway.) Are we only considering Linux/Mac/Windows, and
only recent versions of those?

What's the status of Java and Jython?

| I hesitate to add "is_steady" to time.get_clock_info(), but a boolean
| is not very useful, it would be better to have a number.
| 
| Arguments for time.monotonic() name:
| 
|  - Users are looking for the "monotonic" name
|  - Most of the time, time.monotonic() is a monotonic clock

Again, here, I'm -100 on "most". If I ask for monotonic, it is because I
need one. Given me monotonic or give me death! (Well, an exception or
at any rate something unusable like None.)

[...]
| PS: I already changed time.monotonic() to time.steady() in the PEP :-p

Sigh. They're different things! For all that "steady" is a slightly
vague term, steady and hires and monotonic are independent concepts. Of
course a lot of high quality clocks will embody hires and ideally steady
or monotonic.

This kind of offer-just-one-thing embedded policy is why I feel the API
needs more user control and a polciy free interface, with montonic() et
al providing handy prepackaged policy for the common uses.

If you can provide monotonic (for example, on Linux as you outline),
which _not_ offer it? Offering steady() provides no way for the user to
ask for higher guarentees.

Cheers,
-- 
Cameron Simpson <cs at zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

But in our enthusiasm, we could not resist a radical overhaul of the
system, in which all of its major weaknesses have been exposed, analyzed,
and replaced with new weaknesses.       - Bruce Leverett