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
On Sat, Mar 24, 2012 at 00:36, Victor Stinner victor.stin...@gmail.com 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
On Fri, 23 Mar 2012 22:38:19 -0500
Brian Curtin br...@python.org wrote:
On Fri, Mar 23, 2012 at 18:38, Yury Selivanov yselivanov...@gmail.com 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
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
- 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
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/issue14397
On Sat, Mar 24, 2012 at 4:38 AM, Brian Curtin br...@python.org wrote:
On Fri, Mar 23, 2012 at 18:38, Yury Selivanov yselivanov...@gmail.com 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
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
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
On Mar 23, 2012 6:25 PM, Victor Stinner victor.stin...@gmail.com 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
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
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:
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
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
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
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
- 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
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
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:
- 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
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
On Fri, Mar 23, 2012 at 18:38, Yury Selivanov yselivanov...@gmail.com 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
On Fri, Mar 23, 2012 at 4:25 PM, Victor Stinner
victor.stin...@gmail.com 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
23 matches
Mail list logo
