[Python-Dev] PEP 418: rename time.monotonic() to time.steady()?

Cameron Simpson cs at zip.com.au
Wed Apr 4 01:31:20 CEST 2012

[ Returning at more leisure... ]

On 04Apr2012 07:53, I wrote:
| On 03Apr2012 13:26, Victor Stinner <victor.stinner at gmail.com> wrote:
| | I would to rename time.monotonic() to time.steady() in the PEP 418 for
| | the following reasons:
| |  - time.steady() may fallback to the system clock which is not
| | monotonic, it's strange to have to check for
| | time.get_clock_info('monotonic')['is_monotonic']

This I agree with. You should never need to do that.

| |  - time.steady() uses GetTickCount() instead of
| | QueryPerformanceCounter() whereas both are monotonic, but
| | QueryPerformanceCounter() is not steady

This is an example of where I think my pick-a-clock API can help people;
we should in some fashion offer all or most of the system clocks. Of
course monotonic() or steady() stould itself pick one, whatever people
agree is the best choice for those modes. But we may as well offer the
rest if it is easy; not with their own functions - that would be
platform specific - but findable.

| | Python steady clock will be different than the C++ definition.

[ BTW, you've a typo in here:
  with the word "Specifiction", however apt that exciting new word may

You say "will be different", and since the C++ may not be adjusted maybe that
is reasonable, but there's no Python definition in the PEP for "steady" at
present. Of course, people are still bickering, but perhaps you should whack
one in as a reference for the bickering.

| | You may argue that time.steady() is not always steady: it may fallback
| | to the system clock which is adjusted by NTP and can jump
| | backward/forward with a delta greater than 1 hour.
| An HOUR ?!?!?

I'd like to apologise for my shrill tone here.

I still think a clock that stepped by an hour is grotesquely
non-steady. (Why an hour, BTW?  I'd hope it is not related to any
timezone summer/winter localtime presentation shift notions.)

I think Kristj\341n Valur J\363nsson is on point when he says "There is
no such thing as steady time", but the notion is very attractive. If
you're going to return a "steady" clock you should be able to find out
how steady that is, for example in maximum step size (adjustment in
alignment with "real time") in seconds. I think if I got 3600 from such
a query I'd decide it was not steady enough and choose not to rely on
it. (Or print all results output in blinking red text:-)

Cameron Simpson <cs at zip.com.au> DoD#743

186,282 miles per second - Not just a good idea, It's the Law!

More information about the Python-Dev mailing list