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 prio
> I don't see what is the use case requiring a is truly monotonic clock.
A clock that is purely monotonic may not be useful. However, people
typically imply that it will have a certain minimum progress (seconds
advanced/real seconds passed). Then you can use it for timeouts.
Regards,
Martin
_
On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin wrote:
> On Fri, Mar 23, 2012 at 18:38, Yury Selivanov 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 function
>> Oh, I was not aware of this issue. Do you suggest to not use
>> QueryPerformanceCounter() on Windows to implement a monotonic clock?
>
>
> I do not have an opinion on the best way to implement monotonic to guarantee
> that it actually is monotonic.
I opened an issue:
http://bugs.python.org/issu
>> - 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 o
> 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 lo
On Fri, 23 Mar 2012 22:38:19 -0500
Brian Curtin wrote:
> On Fri, Mar 23, 2012 at 18:38, Yury Selivanov 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 fu
On Sat, Mar 24, 2012 at 00:36, Victor Stinner 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(
On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner
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(stric
On Fri, Mar 23, 2012 at 18:38, Yury Selivanov 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
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
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
Oh, I was not aware of this issue. Do you suggest to not us
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
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 t
>> - 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
QueryPerfor
> 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 in
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
_
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 i
>> 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
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:
>
>
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
> 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 tim
On Mar 23, 2012 6:25 PM, "Victor Stinner" 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=Tr
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 No
24 matches
Mail list logo
