[Python-Dev] PEP 418: Add monotonic clock (original) (raw)

Yury Selivanov yselivanov.ml at gmail.com
Wed Mar 28 16:56:34 CEST 2012

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.

More information about the Python-Dev mailing list