> Wait, what? > I already thought we, several days ago, decided that "steady" was a > *terrible* name, and that monotonic should *not* fall back to the > system clock.
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. Then we can design a separate inquiry API (doesn't have to be complex as long as it's extensible -- a dict or object with a few predefined keys or attributes sounds good enough) for apps that want to know more about how the timer they're using is actually implemented." I added time.get_clock_info() so the user can check if the clock is monotonic or not. Victor _______________________________________________ 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
