[Python-Dev] PEP 418: Add monotonic clock

[Yury Selivanov]

On 2012-03-28, at 10:36 AM, Nick Coghlan wrote:

> Monotonicity is fairly easy to guarantee - you just remember the last
> value you returned and ensure you never return a lower value than that
> for the lifetime of the process.

As I said in my previous mail - I don't think we should ever do that.

Time may jump back and forth, and with your approach it will result in
monotonic() being completely unusable.  If time jumps back for N minutes,
or years, that leads to completely broken expectations for timeouts for N 
minutes or years correspondingly (and that's just the timeouts case, I'm
sure that there are much more critical time-related use-cases.)

If monotonic() will utilize such hack, you add nothing usable in stdlib.
Every serious framework or library will have to re-implement it using
only OS-level functions, and *FAIL* if the OS doesn't support monotonic
time.  Fail, because such framework can't guarantee that it will work 
correctly.

So I think time module should have only one new function: monotonic(),
and this function should be only available if OS provides the underlying
functionality.

No need for steady(), try_monotonic() and other hacks.  Each module
can decide if its dependancy on monotonic is critical or not, and
if it is not, you can always have:

  try:
    from time import monotonic as _time
  except ImportError:
    from time import time as _time

That's how lots of code is written these days, like using 'epoll' if 
available, and fallback to 'select' if not.  Why don't you try to
abstract differences between them in the standard library?  So I see 
no point in adding some loose abstractions to the stdlib now.

-
Yury