Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

PEP 418: rename time.monotonic() to time.steady()?

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


victor.stinner at gmail

Apr 3, 2012, 4:26 AM

Post #1 of 12 (270 views)
Permalink
PEP 418: rename time.monotonic() to time.steady()?

Hi,

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']
- time.steady() uses GetTickCount() instead of
QueryPerformanceCounter() whereas both are monotonic, but
QueryPerformanceCounter() is not steady

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

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. In practice, there
is only one operating system that does not provide a monotonic clock:
GNU/Hurd.

I hesitate to add "is_steady" to time.get_clock_info(), but a boolean
is not very useful, it would be better to have a number.

Arguments for time.monotonic() name:

- Users are looking for the "monotonic" name
- Most of the time, time.monotonic() is a monotonic clock

--

On Linux, we might use CLOCK_MONOTONIC for time.steady() and
CLOCK_MONOTONIC_RAW for time.highres(). The NTP daemon Linux on Linux
uses a reliable clock to adjust CLOCK_MONOTONIC frequency and so
CLOCK_MONOTONIC is steady and it may go backward in a short period,
whereas CLOCK_MONOTONIC_RAW cannot go backward and so may fit closer
time.highres() requirements.

Currently, CLOCK_MONOTONIC is used for time.highres() and
time.steady() in the PEP.

--

NTP on Linux should only slew CLOCK_MONOTONIC, not step it. But it
looks like there was a bug in the Linux kernel 2.6.31: CLOCK_MONOTONIC
goes backward sometimes. Bug introduced in 2.6.31 by (August 14,
2009):
https://github.com/torvalds/linux/commit/0a54419836254a27baecd9037103171bcbabaf67
and fixed in the kernel 2.6.32 by (November 16, 2009):
https://github.com/torvalds/linux/commit/0696b711e4be45fa104c12329f617beb29c03f78

Someone had the bug:
http://stackoverflow.com/questions/3657289/linux-clock-gettimeclock-monotonic-strange-non-monotonic-behavior

Victor
PS: I already changed time.monotonic() to time.steady() in the PEP :-p
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


rdmurray at bitdance

Apr 3, 2012, 12:12 AM

Post #2 of 12 (250 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

On Tue, 03 Apr 2012 22:42:37 +0800, Matt Joiner <anacrolix [at] gmail> wrote:
> The discussion has completed degenerated. There are several different
> clocks here, and several different agendas.

It's probably time to do a reset. Read Victor's PEP, and help
him edit it so that it accurately reflects the various arguments.

Then we can bikeshed some more based on the language in the PEP :)

--David
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


regebro at gmail

Apr 3, 2012, 7:13 AM

Post #3 of 12 (253 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

On Tue, Apr 3, 2012 at 13:26, Victor Stinner <victor.stinner [at] gmail> wrote:
> Hi,
>
> 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']
>  - time.steady() uses GetTickCount() instead of
> QueryPerformanceCounter() whereas both are monotonic, but
> QueryPerformanceCounter() is not steady

Wait, what?
I already thought we, several days ago, decided that "steady" was a
*terrible* name, and that monotonic should *not* fall back to the
system clock.

It seems that we are going in circles with this. Now we are back to
where we started. Now we have a time.steady() which may not be steady
and a time.highres() which may not be high resolution.

//Lennart
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


kristjan at ccpgames

Apr 3, 2012, 7:27 AM

Post #4 of 12 (247 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

> -----Original Message-----
> From: python-dev-bounces+kristjan=ccpgames.com [at] python
> [mailto:python-dev-bounces+kristjan=ccpgames.com [at] python] On
> Behalf Of Lennart Regebro
> Sent: 3. apríl 2012 14:14
> To: Victor Stinner
> Cc: Python Dev
> Subject: Re: [Python-Dev] PEP 418: rename time.monotonic() to
> time.steady()?
>
> On Tue, Apr 3, 2012 at 13:26, Victor Stinner <victor.stinner [at] gmail>
> wrote:
> > Hi,
> >
> > 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']
> >  - time.steady() uses GetTickCount() instead of
> > QueryPerformanceCounter() whereas both are monotonic, but
> > QueryPerformanceCounter() is not steady
>
> Wait, what?
> I already thought we, several days ago, decided that "steady" was a
> *terrible* name, and that monotonic should *not* fall back to the system
> clock.
>
> It seems that we are going in circles with this. Now we are back to where we
> started. Now we have a time.steady() which may not be steady and a
> time.highres() which may not be high resolution.

There is no such thing as steady time. I think we are trying to solve a non-existing problem here.
K

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


anacrolix at gmail

Apr 3, 2012, 7:42 AM

Post #5 of 12 (246 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

The discussion has completed degenerated. There are several different
clocks here, and several different agendas.


victor.stinner at gmail

Apr 3, 2012, 2:14 PM

Post #6 of 12 (242 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

> Wait, what?
> I already thought we, several days ago, decided that "steady" was a
> *terrible* name, and that monotonic should *not* fall back to the
> system clock.

Copy of a more recent Guido's email:
http://mail.python.org/pipermail/python-dev/2012-March/118322.html
"Anyway, the more I think about it, the more I believe these functions
should have very loose guarantees, and instead just cater to common
use cases -- availability of a timer with minimal fuss is usually more
important than the guarantees. So forget the idea about one version
that falls back to time.time() and another that doesn't -- just always
fall back to time.time(), which is (almost) always better than
failing.

Then we can design a separate inquiry API (doesn't have to be complex
as long as it's extensible -- a dict or object with a few predefined
keys or attributes sounds good enough) for apps that want to know more
about how the timer they're using is actually implemented."

I added time.get_clock_info() so the user can check if the clock is
monotonic or not.

Victor
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 3, 2012, 2:53 PM

Post #7 of 12 (237 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

On 03Apr2012 13:26, Victor Stinner <victor.stinner [at] gmail> 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']
| - time.steady() uses GetTickCount() instead of
| QueryPerformanceCounter() whereas both are monotonic, but
| QueryPerformanceCounter() is not steady
|
| Python steady clock will be different than the C++ definition.
|
| 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 have to say I'm -100 on any proposal where time.monotonic() returns
non-monotonic time and likewise for time.steady() returning unsteady
time.

| In practice, there
| is only one operating system that does not provide a monotonic clock:
| GNU/Hurd.

I'd have thought practically any early UNIX falls into this category.
And any number of other niche things. (Yes I know Python doesn't run on
everything anyway.) Are we only considering Linux/Mac/Windows, and
only recent versions of those?

What's the status of Java and Jython?

| I hesitate to add "is_steady" to time.get_clock_info(), but a boolean
| is not very useful, it would be better to have a number.
|
| Arguments for time.monotonic() name:
|
| - Users are looking for the "monotonic" name
| - Most of the time, time.monotonic() is a monotonic clock

Again, here, I'm -100 on "most". If I ask for monotonic, it is because I
need one. Given me monotonic or give me death! (Well, an exception or
at any rate something unusable like None.)

[...]
| PS: I already changed time.monotonic() to time.steady() in the PEP :-p

Sigh. They're different things! For all that "steady" is a slightly
vague term, steady and hires and monotonic are independent concepts. Of
course a lot of high quality clocks will embody hires and ideally steady
or monotonic.

This kind of offer-just-one-thing embedded policy is why I feel the API
needs more user control and a polciy free interface, with montonic() et
al providing handy prepackaged policy for the common uses.

If you can provide monotonic (for example, on Linux as you outline),
which _not_ offer it? Offering steady() provides no way for the user to
ask for higher guarentees.

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

But in our enthusiasm, we could not resist a radical overhaul of the
system, in which all of its major weaknesses have been exposed, analyzed,
and replaced with new weaknesses. - Bruce Leverett
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ethan at stoneleaf

Apr 3, 2012, 3:10 PM

Post #8 of 12 (237 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

Cameron Simpson wrote:
> Sigh. They're different things! For all that "steady" is a slightly
> vague term, steady and hires and monotonic are independent concepts. Of
> course a lot of high quality clocks will embody hires and ideally steady
> or monotonic.
>
> This kind of offer-just-one-thing embedded policy is why I feel the API
> needs more user control and a polciy free interface, with montonic() et
> al providing handy prepackaged policy for the common uses.

+1

~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


cs at zip

Apr 3, 2012, 4:31 PM

Post #9 of 12 (237 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

[ Returning at more leisure... ]

On 04Apr2012 07:53, I wrote:
| On 03Apr2012 13:26, Victor Stinner <victor.stinner [at] gmail> 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:
http://www.python.org/dev/peps/pep-0418/#id22
with the word "Specifiction", however apt that exciting new word may
seem:-)
]

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:-)

Cheers,
--
Cameron Simpson <cs [at] zip> DoD#743
http://www.cskk.ezoshosting.com/cs/

186,282 miles per second - Not just a good idea, It's the Law!
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


breamoreboy at yahoo

Apr 3, 2012, 5:06 PM

Post #10 of 12 (235 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

On 04/04/2012 00:31, Cameron Simpson wrote:
> [ Returning at more leisure... ]
> 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:-)
>
> Cheers,

IIRC time.steady() has been rejected umpteen times. Someone (apologies,
it's a long thread :) suggested time.steadier() [or time.steadiest() ?]
implying that it's the best that can be done. I'd go with that unless
someboby has a better option, but there's been so many suggested that I
might even have to read the PEP :)

The more that this thread runs, the more I get the impression that we're
trying to make mountains out of electrons. Having said that, I know
that the conservative nature of Python development is the best approach
here wrt the API. Rather short term pain and long term gain than vice
versa.

Just my 2p worth.

--
Cheers.

Mark Lawrence.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


regebro at gmail

Apr 4, 2012, 8:30 AM

Post #11 of 12 (229 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

On Tue, Apr 3, 2012 at 23:14, Victor Stinner <victor.stinner [at] gmail> wrote:
>> Wait, what?
>> I already thought we, several days ago, decided that "steady" was a
>> *terrible* name, and that monotonic should *not* fall back to the
>> system clock.
>
> Copy of a more recent Guido's email:
> http://mail.python.org/pipermail/python-dev/2012-March/118322.html
> "Anyway, the more I think about it, the more I believe these functions
> should have very loose guarantees, and instead just cater to common
> use cases -- availability of a timer with minimal fuss is usually more
> important than the guarantees. So forget the idea about one version
> that falls back to time.time() and another that doesn't -- just always
> fall back to time.time(), which is (almost) always better than
> failing.

I disagree with this, mainly for the reason that there isn't any good
names for these functions. "hopefully_monotonic()" doesn't really cut
it for me. :-)
I also don't see how it's hard to guarantee that monotonic() is monotonic.

//Lennart
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

Apr 4, 2012, 8:33 AM

Post #12 of 12 (232 views)
Permalink
Re: PEP 418: rename time.monotonic() to time.steady()? [In reply to]

On Wed, 4 Apr 2012 17:30:26 +0200
Lennart Regebro <regebro [at] gmail> wrote:
> > Copy of a more recent Guido's email:
> > http://mail.python.org/pipermail/python-dev/2012-March/118322.html
> > "Anyway, the more I think about it, the more I believe these functions
> > should have very loose guarantees, and instead just cater to common
> > use cases -- availability of a timer with minimal fuss is usually more
> > important than the guarantees. So forget the idea about one version
> > that falls back to time.time() and another that doesn't -- just always
> > fall back to time.time(), which is (almost) always better than
> > failing.
>
> I disagree with this, mainly for the reason that there isn't any good
> names for these functions. "hopefully_monotonic()" doesn't really cut
> it for me. :-)

monotonic(fallback=False) doesn't look horrible to me (assuming a
default value of False for the `fallback` parameter).

> I also don't see how it's hard to guarantee that monotonic() is monotonic.

I think we are speaking about a system-wide monotonic clock (i.e., you
can compare values between processes). Otherwise it's probably quite
easy indeed.

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.