> 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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
