On Wed, 4 Apr 2012 17:30:26 +0200
Lennart Regebro
Copy of a more recent Guido's email: http://mail.python.org/pipermail/python-dev/2012-March/118322.html "Anyway, the more I think about it, the more I believe these functions should have very loose guarantees, and instead just cater to common use cases -- availability of a timer with minimal fuss is usually more important than the guarantees. So forget the idea about one version that falls back to time.time() and another that doesn't -- just always fall back to time.time(), which is (almost) always better than failing.
I disagree with this, mainly for the reason that there isn't any good names for these functions. "hopefully_monotonic()" doesn't really cut it for me. :-)
monotonic(fallback=False) doesn't look horrible to me (assuming a default value of False for the `fallback` parameter).
I also don't see how it's hard to guarantee that monotonic() is monotonic.
I think we are speaking about a system-wide monotonic clock (i.e., you can compare values between processes). Otherwise it's probably quite easy indeed. Regards Antoine.