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

Mailing List Archive: Python: Dev

Rename time.steady(strict=True) to time.monotonic()?

 

 

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


victor.stinner at gmail

Mar 23, 2012, 4:25 PM

Post #1 of 21 (515 views)
Permalink
Rename time.steady(strict=True) to time.monotonic()?

Hi,

time.steady(strict=True) looks to be confusing for most people, some
of them don't understand the purpose of the flag and others don't like
a flag changing the behaviour of the function.

I propose to replace time.steady(strict=True) by time.monotonic().
That would avoid the need of an ugly NotImplementedError: if the OS
has no monotonic clock, time.monotonic() will just not exist.

So we will have:

- time.time(): realtime, can be adjusted by the system administrator
(manually) or automatically by NTP
- time.clock(): monotonic clock on Windows, CPU time on UNIX
- time.monotonic(): monotonic clock, its speed may or may not be
adjusted by NTP but it only goes forward, may raise an OSError
- time.steady(): monotonic clock or the realtime clock, depending on
what is available on the platform (use monotonic in priority). may be
adjusted by NTP or the system administrator, may go backward.

time.steady() is something like:

try:
return time.monotonic()
except (NotImplementError, OSError):
return time.time()

time.time(), time.clock(), time.steady() are always available, whereas
time.monotonic() will not be available on some platforms.

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


brian at python

Mar 23, 2012, 4:28 PM

Post #2 of 21 (503 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On Mar 23, 2012 6:25 PM, "Victor Stinner" <victor.stinner [at] gmail> wrote:
>
> Hi,
>
> time.steady(strict=True) looks to be confusing for most people, some
> of them don't understand the purpose of the flag and others don't like
> a flag changing the behaviour of the function.
>
> I propose to replace time.steady(strict=True) by time.monotonic().
> That would avoid the need of an ugly NotImplementedError: if the OS
> has no monotonic clock, time.monotonic() will just not exist.
>
> So we will have:
>
> - time.time(): realtime, can be adjusted by the system administrator
> (manually) or automatically by NTP
> - time.clock(): monotonic clock on Windows, CPU time on UNIX
> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
>
> time.steady() is something like:
>
> try:
> return time.monotonic()
> except (NotImplementError, OSError):
> return time.time()
>
> time.time(), time.clock(), time.steady() are always available, whereas
> time.monotonic() will not be available on some platforms.
>
> Victor

This seems like it should have been a PEP, or maybe should become a PEP.


victor.stinner at gmail

Mar 23, 2012, 4:36 PM

Post #3 of 21 (504 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

> This seems like it should have been a PEP, or maybe should become a PEP.

I replaced time.wallclock() by time.steady(strict=False) and
time.monotonic() by time.steady(strict=True). This change solved the
naming issue of time.wallclock(), but it was a bad idea to merge
monotonic() feature into time.steady(). It looks like everybody
agrees, am I wrong?

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


yselivanov.ml at gmail

Mar 23, 2012, 4:38 PM

Post #4 of 21 (505 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
> This seems like it should have been a PEP, or maybe should become a PEP.

Why? AFAIK Victor just proposes to add two new functions: monotonic() and
steady().

time() and clock() do already exist and won't be changed.

-
Yury
_______________________________________________
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


yselivanov.ml at gmail

Mar 23, 2012, 4:42 PM

Post #5 of 21 (506 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On 2012-03-23, at 7:25 PM, Victor Stinner wrote:

> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
>
> time.steady() is something like:
>
> try:
> return time.monotonic()
> except (NotImplementError, OSError):
> return time.time()

Is the use of weak monotonic time so wide-spread in the stdlib that we
need the 'steady()' function? If it's just two modules then it's not
worth adding it.

-
Yury
_______________________________________________
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


victor.stinner at gmail

Mar 23, 2012, 4:51 PM

Post #6 of 21 (506 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

>> time.steady() is something like:
>>
>> try:
>>  return time.monotonic()
>> except (NotImplementError, OSError):
>>  return time.time()
>
> Is the use of weak monotonic time so wide-spread in the stdlib that we
> need the 'steady()' function?  If it's just two modules then it's not
> worth adding it.

The Python standard library is not written to be used by Python
itself, but by others. The try/except is a common pattern when
applications use a monotonic clock. I suppose that quite all
applications use this try/except pattern.

I don't see what is the use case requiring a is truly monotonic clock.

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


steve at pearwood

Mar 23, 2012, 5:02 PM

Post #7 of 21 (504 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

Victor Stinner wrote:
[...]
> So we will have:
>
> - time.time(): realtime, can be adjusted by the system administrator
> (manually) or automatically by NTP
> - time.clock(): monotonic clock on Windows, CPU time on UNIX
> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError

This all sounds good to me. +1 up to this point.

Question: under what circumstances will monotonic() exist but raise OSError?


> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.

What makes this "steady", given that it can be adjusted and it can go
backwards? Doesn't sound steady to me.

Is steady() merely a convenience function to avoid the user having to write
something like this?

try:
mytimer = time.monotonic
except AttributeError:
mytimer = time.time


or inline:

> try:
> return time.monotonic()
> except (NotImplementError, OSError):
> return time.time()

Should that be (AttributeError, OSError) instead?



--
Steven
_______________________________________________
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


steve at pearwood

Mar 23, 2012, 5:16 PM

Post #8 of 21 (503 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

Victor Stinner wrote:

> - time.clock(): monotonic clock on Windows, CPU time on UNIX

Actually, I think that is not correct. Or at least *was* not correct in 2006.

http://bytes.com/topic/python/answers/527849-time-clock-going-backwards




--
Steven

_______________________________________________
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


victor.stinner at gmail

Mar 23, 2012, 5:25 PM

Post #9 of 21 (502 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

> Question: under what circumstances will monotonic() exist but raise OSError?

On Windows, OSError is raised if QueryPerformanceFrequency fails.
Extract of Microsoft doc:

"If the function fails, the return value is zero. To get extended
error information, call GetLastError. For example, if the installed
hardware does not support a high-resolution performance counter, the
function fails."

On UNIX, OSError is raised if clock_gettime(CLOCK_MONOTONIC) fails.
Extract of clock_gettime() doc:

"ERRORS
EINVAL The clk_id specified is not supported on this system."

It may occur if the libc exposes CLOCK_MONOTONIC but the kernel
doesn't support it. I don't know if it can occur in practice.

>> - time.steady(): monotonic clock or the realtime clock, depending on
>> what is available on the platform (use monotonic in priority). may be
>> adjusted by NTP or the system administrator, may go backward.
>
> What makes this "steady", given that it can be adjusted and it can go
> backwards? Doesn't sound steady to me.

In practice, it will be monotonic in most cases. "steady" name is used
instead of "monotonic" because it may not be monotonic is other cases.

> Is steady() merely a convenience function to avoid the user having
> to write something like this?

steady() remembers if the last call to monotonic failed or not. The
real implementation is closer to something like:

def steady():
if not steady.has_monotonic:
return time.time()
try:
return time.monotonic()
except (AttributeError, OSError):
steady.has_monotonic = False
return time.time()
steady.has_monotonic = True

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


victor.stinner at gmail

Mar 23, 2012, 5:45 PM

Post #10 of 21 (507 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

>> - time.clock(): monotonic clock on Windows, CPU time on UNIX
>
>
> Actually, I think that is not correct. Or at least *was* not correct in
> 2006.
>
> http://bytes.com/topic/python/answers/527849-time-clock-going-backwards

Oh, I was not aware of this issue. Do you suggest to not use
QueryPerformanceCounter() on Windows to implement a monotonic clock?

The python-monotonic-time project uses GetTickCount64(), or
GetTickCount(), on Windows. GetTickCount64() was added to Windows
Seven / Server 2008. GetTickCount() overflows after 49 days.
QueryPerformanceCounter() has a better resolution than
GetTickCount[64]().

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


steve at pearwood

Mar 23, 2012, 7:08 PM

Post #11 of 21 (493 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

Victor Stinner wrote:

>> Is steady() merely a convenience function to avoid the user having
>> to write something like this?
>
> steady() remembers if the last call to monotonic failed or not. The
> real implementation is closer to something like:
>
> def steady():
> if not steady.has_monotonic:
> return time.time()
> try:
> return time.monotonic()
> except (AttributeError, OSError):
> steady.has_monotonic = False
> return time.time()
> steady.has_monotonic = True

Does this mean that there are circumstances where monotonic will work for a
while, but then fail?

Otherwise, we would only need to check monotonic once, when the time module is
first loaded, rather than every time it is called. Instead of the above:

# global to the time module
try:
monotonic()
except (NameError, OSError):
steady = time
else:
steady = monotonic



Are there failure modes where monotonic can recover? That is, it works for a
while, then raises OSError, then works again on the next call.

If so, steady will stop using monotonic and never try it again. Is that
deliberate?



--
Steven

_______________________________________________
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


janzert at janzert

Mar 23, 2012, 7:12 PM

Post #12 of 21 (493 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On 3/23/2012 7:25 PM, Victor Stinner wrote:
[snip]
> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.
>
> time.steady() is something like:
>
> try:
> return time.monotonic()
> except (NotImplementError, OSError):
> return time.time()
>

I am surprised that a clock with the name time.steady() has a looser
definition than one called time.monotonic(). To my mind a steady clock
is by definition monotonic but a monotonic one may or may not be steady.

Janzert

_______________________________________________
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


jimjjewett at gmail

Mar 23, 2012, 7:36 PM

Post #13 of 21 (492 views)
Permalink
Rename time.steady(strict=True) to time.monotonic()? [In reply to]

In http://mail.python.org/pipermail/python-dev/2012-March/118024.html
Steven D'Aprano wrote:

> What makes this "steady", given that it can be adjusted
> and it can go backwards?

It is best-effort for steady, but putting "best" in the name would
be an attractive nuisance.

> Is steady() merely a convenience function to avoid the user
> having to write something like this?

> try:
> mytimer = time.monotonic
> except AttributeError:
> mytimer = time.time

That would still be worth doing. But I think the main point is
that the clock *should* be monotonic, and *should* be as precise
as possible.

Given that it returns seconds elapsed (since an undefined start),
perhaps it should be

time.seconds()

or even

time.counter()

-jJ

--

If there are still threading problems with my replies, please
email me with details, so that I can try to resolve them. -jJ

_______________________________________________
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


brian at python

Mar 23, 2012, 8:38 PM

Post #14 of 21 (484 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On Fri, Mar 23, 2012 at 18:38, Yury Selivanov <yselivanov.ml [at] gmail> wrote:
> On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
>> This seems like it should have been a PEP, or maybe should become a PEP.
>
> Why? AFAIK Victor just proposes to add two new functions: monotonic() and
> steady().

We just previously had "Drop time.monotonic() function, rename
time.wallclock() to time.steady()" checked in a few weeks ago, and now
we're renaming a variation on time.steady to time.monotonic? What's
the next move?

I'm not paying close attention here but there's a lot of movement
going on. Figuring out the API before we get too deep is probably a
good idea.
_______________________________________________
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


jyasskin at gmail

Mar 23, 2012, 10:37 PM

Post #15 of 21 (474 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner
<victor.stinner [at] gmail> wrote:
> Hi,
>
> time.steady(strict=True) looks to be confusing for most people, some
> of them don't understand the purpose of the flag and others don't like
> a flag changing the behaviour of the function.
>
> I propose to replace time.steady(strict=True) by time.monotonic().
> That would avoid the need of an ugly NotImplementedError: if the OS
> has no monotonic clock, time.monotonic() will just not exist.
>
> So we will have:
>
> - time.time(): realtime, can be adjusted by the system administrator
> (manually) or automatically by NTP
> - time.clock(): monotonic clock on Windows, CPU time on UNIX
> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError
> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.

Please don't use the word "steady" for something different from what
C++ means by it. C++'s term means "may not be adjusted at all, even by
NTP; proceeds at as close to the rate of real time as the system can
manage" (paraphrased). If the consensus in the Python community is
that a C++-style "steady" clock is unnecessary, then feel free not to
define it. If the consensus is that "monotonic" already means
everything C++ means by "steady", that's fine with me too. I mentioned
it because I thought it might be worth looking at what other languages
were doing in this space, not because I thought it was a nice word
that you should attach your own definitions to.

Jeffrey
_______________________________________________
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

Mar 24, 2012, 1:20 AM

Post #16 of 21 (467 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On Sat, Mar 24, 2012 at 00:36, Victor Stinner <victor.stinner [at] gmail> wrote:
>> This seems like it should have been a PEP, or maybe should become a PEP.
>
> I replaced time.wallclock() by time.steady(strict=False) and
> time.monotonic() by time.steady(strict=True). This change solved the
> naming issue of time.wallclock(), but it was a bad idea to merge
> monotonic() feature into time.steady(). It looks like everybody
> agrees, am I wrong?

Yes. As mentioned time.steady(i_mean_it=True) or
time.steady(no_not_really=True) doesn't make any sense.
Merging the methods may very well make sense, but it should then
return a best case and have no flags.

I think, as it has been hard to reach an agreement on this that the
proposal to only make "stupid" functions that expose the system API's
are the correct thing to do at the moment.

> - time.time(): realtime, can be adjusted by the system administrator
> (manually) or automatically by NTP

Sure.

> - time.clock(): monotonic clock on Windows, CPU time on UNIX

This is for historical reasons, right, because this is what it is now?
Would there be a problem in making time.clock() monotonic on Unix as
well, if it exists?

> - time.monotonic(): monotonic clock, its speed may or may not be
> adjusted by NTP but it only goes forward, may raise an OSError
> if the OS
> has no monotonic clock, time.monotonic() will just not exist.

Works for me,

> - time.steady(): monotonic clock or the realtime clock, depending on
> what is available on the platform (use monotonic in priority). may be
> adjusted by NTP or the system administrator, may go backward.

So it's time.may_or_may_not_be_steady()

I don't mind the function, but the name should not be steady(). It's
implementation is also so trivial that those who want a monotonic if
it exists, but a normal clock otherwise, can simply just do

> try:
> return time.monotonic()
> except (NotImplementError, OSError):
> return time.time()

themselves.
//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

Mar 24, 2012, 1:39 AM

Post #17 of 21 (467 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On Fri, 23 Mar 2012 22:38:19 -0500
Brian Curtin <brian [at] python> wrote:
> On Fri, Mar 23, 2012 at 18:38, Yury Selivanov <yselivanov.ml [at] gmail> wrote:
> > On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
> >> This seems like it should have been a PEP, or maybe should become a PEP.
> >
> > Why? AFAIK Victor just proposes to add two new functions: monotonic() and
> > steady().
>
> We just previously had "Drop time.monotonic() function, rename
> time.wallclock() to time.steady()" checked in a few weeks ago, and now
> we're renaming a variation on time.steady to time.monotonic? What's
> the next move?
>
> I'm not paying close attention here but there's a lot of movement
> going on. Figuring out the API before we get too deep is probably a
> good idea.

Agreed with Brian. Obviously the API needs further discussion, judging
by Victor's own multiple changes of mind on the subject.

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


victor.stinner at gmail

Mar 24, 2012, 3:35 AM

Post #18 of 21 (467 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

> Does this mean that there are circumstances where monotonic will work for a
> while, but then fail?

No. time.monotonic() always work or always fail. If monotonic()
failed, steady() doesn't call it again.

> Otherwise, we would only need to check monotonic once, when the time module
> is first loaded, rather than every time it is called. Instead of the above:
>
> # global to the time module
> try:
>    monotonic()
> except (NameError, OSError):
>    steady = time
> else:
>    steady = monotonic

I implemented steady differently to avoid the need of calling
monotonic at Python startup. Calling monotonic at startup would be an
extra useless system call.

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


victor.stinner at gmail

Mar 24, 2012, 3:37 AM

Post #19 of 21 (464 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

>> - time.monotonic(): monotonic clock, its speed may or may not be
>> adjusted by NTP but it only goes forward, may raise an OSError
>> - time.steady(): monotonic clock or the realtime clock, depending on
>> what is available on the platform (use monotonic in priority). may be
>> adjusted by NTP or the system administrator, may go backward.
>>
>
> I am surprised that a clock with the name time.steady() has a looser
> definition than one called time.monotonic(). To my mind a steady clock is by
> definition monotonic but a monotonic one may or may not be steady.

Do you suggest another name?

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


stephen at xemacs

Mar 24, 2012, 8:39 AM

Post #20 of 21 (464 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin <brian [at] python> wrote:
> On Fri, Mar 23, 2012 at 18:38, Yury Selivanov <yselivanov.ml [at] gmail> wrote:
>> On 2012-03-23, at 7:28 PM, Brian Curtin wrote:
>>> This seems like it should have been a PEP, or maybe should become a PEP.
>>
>> Why? AFAIK Victor just proposes to add two new functions: monotonic() and
>> steady().

Need for PEPs is not determined by volume of content, but by
amount of controversy and lack of clarity.

Isn't it obvious that there's quite a bit of disagreement about the
definitions of "monotonic" and "steady", and about whether these
functions should be what they say they are or "best effort", and
so on?

+1 for a PEP.

> We just previously had "Drop time.monotonic() function, rename
> time.wallclock() to time.steady()" checked in a few weeks ago, and now
> we're renaming a variation on time.steady to time.monotonic? What's
> the next move?
>
> I'm not paying close attention here but there's a lot of movement
> going on. Figuring out the API before we get too deep is probably a
> good idea.

I have been following the thread but don't have the technical
knowledge to be sure what's going on.

What I have decided is that I won't be using any function named
time.steady() or time.monotonic() because neither one seems
likely to guarantee the property it's named for, and by the time I
have a use case (I don't have one now, I'm just an habitual lurker)
I'll have forgotten the conclusion of this thread, but not the deep
feelings of FUD.

To get me on board (not that there's any particular reason you
should care, but just in case), you're going to need to respect
EIBTI. By that I mean that a monotonic clock is monotonic,
and if not available at instantiation, an Exception will be
raised. Similarly for a steady clock. There is no such thing
as "best effort" here for clocks with these names.

The default clock should be best effort. If that is for some
reason "expensive", then there should be a
"time.windup_clock()" to provide an unreliable resource-
conserving clock.

FWIW, I understand that

(1) A monotonic clock is one that never goes backwards. If
precision allows, it should always go forwards (ie, repeated
calls should always produce strictly larger time values).

(2) A steady clock is strictly monotonic, and when a discrepancy
against "true time" is detected (however that might happen), it
slews its visible clock until the discrepancy is eliminated, so that
one clock second always means something "close" to one second.
_______________________________________________
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


janzert at janzert

Mar 25, 2012, 12:48 PM

Post #21 of 21 (458 views)
Permalink
Re: Rename time.steady(strict=True) to time.monotonic()? [In reply to]

On 3/24/2012 6:37 AM, Victor Stinner wrote:
>>> - time.monotonic(): monotonic clock, its speed may or may not be
>>> adjusted by NTP but it only goes forward, may raise an OSError
>>> - time.steady(): monotonic clock or the realtime clock, depending on
>>> what is available on the platform (use monotonic in priority). may be
>>> adjusted by NTP or the system administrator, may go backward.
>>>
>>
>> I am surprised that a clock with the name time.steady() has a looser
>> definition than one called time.monotonic(). To my mind a steady clock is by
>> definition monotonic but a monotonic one may or may not be steady.
>
> Do you suggest another name?
>
> Victor

I can't think of a word or short phrase that adequately describes that
behavior, no. But that may just be because I also don't see any use case
for it either.

To me the more useful function would be one that used the OS monotonic
clock when available and failing that used the realtime clock but cached
the previous returned value and ensured that all values returned obeyed
the monotonic property still. But I don't see why that function
shouldn't just be time.monotonic().

Janzert

_______________________________________________
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.