This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients lemburg, neologix, vstinner
Date 2012-04-03.11:30:38
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
In-reply-to <>
> I think you need to reconsider the time.steady() name you're using
> in the PEP. For practical purposes, it's better to call it
> time.monotonic()

I opened a new thread on python-dev to discuss this topic.

> and only make the function available if the OS provides
> a monotonic clock.

Oh, I should explain this choice in the PEP. Basically, the idea is to
provide a best-effort portable function.

> The fallback to time.time() is not a good idea, since then the programmer
> has to check whether the timer really provides the features she's after
> every time it gets used.

Nope, time.get_clock_info('steady') does not change at runtime. So it
can only be checked once.

> Instead of trying to tweak all the different clocks and timers into
> a single function, wouldn't it be better to expose each kind as a
> different function and then let the programmer decide which fits
> best ?!

This is a completly different approach. It should be discussed on
python-dev, not in the bug tracker please. I think that Python can
help the developer to write portable code by providing high-level
functions because clock properties are well known (e.g. see

> BTW: Thanks for the research you've done on the different clocks and
> timers. That's very useful information.

You're welcome.
Date User Action Args
2012-04-03 11:30:39vstinnersetrecipients: + vstinner, lemburg, neologix
2012-04-03 11:30:38vstinnerlinkissue14428 messages
2012-04-03 11:30:38vstinnercreate