On Wed, 4 Apr 2012 17:30:26 +0200 Lennart Regebro <rege...@gmail.com> wrote: > > 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. _______________________________________________ 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
