> What's wrong with "time.time()" again? As documented in > http://docs.python.org/py3k/library/time.html it makes no guarantees, > and specifically there is *no* guarantee that it will ever behave > *badly*<wink/>. Of course, we'll have to guarantee that, if a > badly-behaved clock is available, users can get access to it, so call > that time._time(). I'm not sure I understand your suggestion correctly, but replacing time.time() by time.monotonic() with fallback won't work, because time.monotonic() isn't wall-clock time: it can very well use an arbitrary reference point (most likely system start-up time). As for the hires() function, since there's no guarantee whatsoever that it does provide a better resolution than time.time(), this would be really misleading IMHO.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4