On 2012-03-28, at 11:35 AM, Nick Coghlan wrote:
> So, the primary use case is that we want to replace many of the
> time.time() calls in the standard library with time.monotonic() calls.
> To avoid backwards compatibility problems in the cross-platform
> support, that means time.monotonic() *must be available on every
> platform that currently provides time.time()*.
OK. I got your point. And also I've just realized what I dislike about
the way you want to implement the fallback. The main problem is that
I treat the situation when time jumps backward as an exception, because,
again, if you have timeouts you may get those timeouts to never be
executed. So let's make the "try_monotonic()" function (or whatever
name will be chosen) this way (your original code edited):
def _make_monotic():
try:
# Use underlying system monotonic clock if we can
return _monotonic
except NameError:
_tick = time()
def monotic():
nonlocal _time
_new_tick = time()
if _new_tick <= _tick:
raise RuntimeError('time was adjusted backward')
_tick = _new_tick
return _new_tick
return monotonic
try_monotonic = _make_monotonic()
At least this approach tries to follow some of the python's zen.
-
Yury
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
