On Tue, Mar 13, 2012 at 6:03 PM, Victor Stinner <victor.stin...@gmail.com> wrote: >> I agree that it's better to have only one of these. I also think if we >> offer it we should always have it -- if none of the implementations >> are available, I guess you could fall back on returning time.time(), >> with some suitable offset so people don't think it is always the same. >> Maybe it could be called realtime()? > > For a concrete use case, see for example: > http://bugs.python.org/issue14222 > > I just wrote two patches, for the queue and threading modules, using > time.monotonic() if available, with a fallback to time.time(). My > patches call time.monotonic() to ensure that it doesn't fail with > OSError. > > I suppose that most libraries and programs will have to implement a > similar fallback.
It seems horrible to force everyone to copy the same silly block of code. The time module itself should implement this once. > We may merge both functions with a flag to be able to disable the > fallback. Example: > > - time.realtime(): best-effort monotonic, with a fallback > - time.realtime(monotonic=True): monotonic, may raise OSError or > NotImplementedError I have no opinions on this or other API details. But please make the function always exist and return something vaguely resembling a monotonic real-time clock. (BTW IMO the docs should state explicitly that it returns a float.) -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
