[Python-Dev] Drop the new time.wallclock() function? (original) (raw)

Jeffrey Yasskin jyasskin at gmail.com
Wed Mar 14 07:16:28 CET 2012

On Tue, Mar 13, 2012 at 6:10 PM, Nadeem Vawda <nadeem.vawda at gmail.com> wrote:

On Wed, Mar 14, 2012 at 3:03 AM, Victor Stinner <victor.stinner at gmail.com> wrote:

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 This was my suggestion - I think it's useful to have the fallback available (since most users will want it), but at the same time we should also cater to users who need a clock that is guaranteed to be monotonic. As an aside, I think "monotonic" is a better name than "realtime"; it conveys the functions purpose more clearly. Then we could call the flag "strict".

While you're bikeshedding:

Some of the drafts of the new C++ standard had a monotonic_clock, which was guaranteed to only go forwards, but which could be affected by system clock updates that went forwards. Because of problems in defining timeouts using an adjustable clock, C++11 instead defines a "steady_clock", which ticks as steadily as the machine/OS/library can ensure, and is definitely not affected by any time adjustments: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3191.htm. I realize that Unix's clock_gettime(CLOCK_MONOTONIC) already includes the steadiness criterion, but the word itself doesn't actually include the meaning.

More information about the Python-Dev mailing list