If we need to decide to which function should be kept - I vote for monotonic. It's extremely useful (even essential) to track timeouts in various schedulers implementations, for example. Quick search also shows the demand for it, as there are questions on stackoverflow.com and few packages on PyPI.
- Yury On 2012-03-13, at 9:03 PM, Victor Stinner 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. > > 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 > > 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/yselivanov.ml%40gmail.com _______________________________________________ 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
