[Python-Dev] Drop the new time.wallclock() function? (original) (raw)
Yury Selivanov yselivanov.ml at gmail.com
Wed Mar 14 02:09:46 CET 2012
- Previous message: [Python-Dev] Drop the new time.wallclock() function?
- Next message: [Python-Dev] Drop the new time.wallclock() function?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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 at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com
- Previous message: [Python-Dev] Drop the new time.wallclock() function?
- Next message: [Python-Dev] Drop the new time.wallclock() function?
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]