On 4/7/2012 5:49 AM, Victor Stinner wrote:
2012/4/7 Janzert:
On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency
>> In any case, NTP is not the only thing that adjusts the clock, e.g. the
>> operating system will adjust the time for daylight savings.
>
> Daylight savings time is not a clock adjustment, at least not in the sense
> this thread has mostly been talking about the word "clock". It doesn't
> affect
On Mon, Apr 9, 2012 at 4:46 PM, Guido van Rossum wrote:
> Is it still? I thought they fixed that ages ago?
>
sadly, no. http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html
On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith wrote:
> >
> > On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz >
> > wrot
Is it still? I thought they fixed that ages ago?
On Mon, Apr 9, 2012 at 4:42 PM, Gregory P. Smith wrote:
>
> On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz
> wrote:
>>
>> On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
>>
>> In any case, NTP is not the only thing that adjusts the clock, e.g.
On Sat, Apr 7, 2012 at 4:56 PM, Glyph Lefkowitz wrote:
> On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
>
> In any case, NTP is not the only thing that adjusts the clock, e.g. the
> operating system will adjust the time for daylight savings.
>
>
> Daylight savings time is not a clock adjustmen
On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote:
> In any case, NTP is not the only thing that adjusts the clock, e.g. the
> operating system will adjust the time for daylight savings.
Daylight savings time is not a clock adjustment, at least not in the sense this
thread has mostly been talki
On 07Apr2012 20:40, Steven D'Aprano wrote:
| Victor Stinner wrote:
| > I don't think that NTP works like that. NTP only uses very smooth
adjustements:
[...]
| > http://www.python.org/dev/peps/pep-0418/#ntp-adjustment
|
| That is incorrect. NTP by default will only slew the clock for small
| dis
2012/4/7 Steven D'Aprano :
> Victor Stinner wrote:
>>
>> 2012/4/7 Janzert :
>>>
>>> On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock
Victor Stinner wrote:
2012/4/7 Janzert :
On 4/5/2012 6:32 AM, Victor Stinner wrote:
I prefer to use CLOCK_MONOTONIC, not because it is also available for
older Linux kernels, but because it is more reliable. Even if the
underlying clock source is unstable (unstable frequency), a delta of
two re
2012/4/7 Janzert :
> On 4/5/2012 6:32 AM, Victor Stinner wrote:
>> I prefer to use CLOCK_MONOTONIC, not because it is also available for
>> older Linux kernels, but because it is more reliable. Even if the
>> underlying clock source is unstable (unstable frequency), a delta of
>> two reads of the C
On 4/5/2012 6:32 AM, Victor Stinner wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's alwa
> 1. The "steadiest" clock on the system. Ideally this would be a steady
> clock, but may not be.
time.monotonic() as proposed in the PEP 418 *is* the steadiest
available clock, but we cannot say that it is steady :-)
> 2. The "most precise" clock on the system. This would have the finest-grain
>
On 4 April 2012 10:33, Steven D'Aprano wrote:
> try:
>from os import bestclock as _bestclock
> except ImportError:
>_bestclock = time
>
My problem here is that "best clock" means different things to different
people (as the number of emails shows).
I think exposing specific clocks is al
On Thu, Apr 5, 2012 at 12:32, Victor Stinner wrote:
> I prefer to use CLOCK_MONOTONIC, not because it is also available for
> older Linux kernels, but because it is more reliable. Even if the
> underlying clock source is unstable (unstable frequency), a delta of
> two reads of the CLOCK_MONOTONIC
On 6 April 2012 02:50, Cameron Simpson wrote:
(Quoted from the Linux manpage)
> All implementations support the system-wide real-time clock, which
> is identified by CLOCK_REALTIME. Its time represents seconds and
> nanoseconds since the Epoch. When its time is changed, timers for
> a
Steven D'Aprano wrote:
Greg Ewing wrote:
the important thing about a clock that it *keeps going forward*
That would be a *strictly* monotonic clock, as opposed to merely monotonic.
Well, yes, but even that's not enough -- it needs to go forward
at a reasonably constant rate, otherwise it's
Cameron Simpson wrote:
I maintain that
"monotonic" still means what I said, and that it is the combination of
the word with "clock" that brings in your other criteria.
I'm not trying to redefine the word "monotonic" in general.
All I'm saying is that *if* the PEP is going to talk about
a "mono
Greg Ewing wrote:
Cameron Simpson wrote:
A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word "monotonic",
but
On 06Apr2012 13:14, Greg Ewing wrote:
| Cameron Simpson wrote:
| > A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
| > polls of the clock. On its own it says nothing about steadiness or
| > correlation with real world time.
|
| No, no, no.
| This is the strict mathematical me
Cameron Simpson wrote:
A monotonic clock never returns t0 > t1 for t0, t1 being two adjacent
polls of the clock. On its own it says nothing about steadiness or
correlation with real world time.
No, no, no.
This is the strict mathematical meaning of the word "monotonic",
but the way it's used
On Apr 5, 2012 11:01 AM, "Guido van Rossum" wrote:
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fix" timeouts) was implemented by the
> application/library code using the timeout (or provided as a separate
> library function), rather than by the clock, since
On 05Apr2012 13:39, Zooko Wilcox-O'Hearn wrote:
| Good job, Victor Stinner on baking the accumulated knowledge of this
| thread into PEP 418. Even though I'm very interested in the topic, I
| haven't been able to digest the whole thread(s) on the list and
| understand what the current collective u
On 05Apr2012 09:56, Guido van Rossum wrote:
| On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby wrote:
| > What's missing is that if you're using a monotonic clock for timeouts, then
| > a monotonically-adjusted system clock can do that, subject to the polling
| > frequency -- it does not break just because
Folks:
Good job, Victor Stinner on baking the accumulated knowledge of this
thread into PEP 418. Even though I'm very interested in the topic, I
haven't been able to digest the whole thread(s) on the list and
understand what the current collective understanding is. The detailed
PEP document helps
On Thu, Apr 5, 2012 at 12:56 PM, Guido van Rossum wrote:
> Depending on the polling frequency sounds like a bad idea, since you
> can't know that you're the only user of the clock. Also depending on
> the use case, too short a timeout may be worse than too long a
> timeout.
Given a small enough
Victor Stinner wrote:
I changed time.monotonic() to not fallback to the system clock exactly
for this reason: Python cannot guess what the developer expects, or
how the developer will use the clock.
Which is exactly why I like Cameron Simpson's approach to selecting a
clock -- let the develope
>> > For timeout purposes in a single process, such a clock is useful. It just
>> > isn't suitable for benchmarks, or for interprocess coordination.
>>
>> I think it would be better if the proposed algorithm (or whatever
>> algorithm to "fix" timeouts) was implemented by the
>> application/library
On Thu, 5 Apr 2012 09:56:19 -0700
Guido van Rossum wrote:
>
> > For timeout purposes in a single process, such a clock is useful. It just
> > isn't suitable for benchmarks, or for interprocess coordination.
>
> I think it would be better if the proposed algorithm (or whatever
> algorithm to "fi
On Thu, Apr 5, 2012 at 9:48 AM, PJ Eby wrote:
>
>
> On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner
> wrote:
>>
>> 2012/4/5 PJ Eby :
>> >> More details why it's hard to define such function and why I dropped
>> >> it from the PEP.
>> >>
>> >> If someone wants to propose again such function ("monot
On Thu, Apr 5, 2012 at 6:34 AM, Victor Stinner wrote:
> 2012/4/5 PJ Eby :
> >> More details why it's hard to define such function and why I dropped
> >> it from the PEP.
> >>
> >> If someone wants to propose again such function ("monotonic or
> >> fallback to system" clock), two issues should be s
On Wed, Apr 4, 2012 at 11:41 PM, Cameron Simpson wrote:
> On 04Apr2012 22:23, PJ Eby wrote:
> | On Apr 4, 2012 7:28 PM, "Victor Stinner"
> wrote:
> | > More details why it's hard to define such function and why I dropped
> | > it from the PEP.
> | >
> | > If someone wants to propose again such
On Thu, 05 Apr 2012 08:32:22 -0700
Ethan Furman wrote:
>
> Steven D'Aprano's synthetic clock is able to partially avoid that
> situation -- worst case is a timeout of double what you asked for -- so
> 10 seconds instead of 5 (which is much better than 3600!).
The remaining issue is that the cl
Cameron Simpson wrote:
On 04Apr2012 22:23, PJ Eby wrote:
| On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote:
| > More details why it's hard to define such function and why I dropped
| > it from the PEP.
| >
| > If someone wants to propose again such function ("monotonic or
| > fallback to system"
2012/4/5 PJ Eby :
>> More details why it's hard to define such function and why I dropped
>> it from the PEP.
>>
>> If someone wants to propose again such function ("monotonic or
>> fallback to system" clock), two issues should be solved:
>>
>> - name of the function
>> - description of the funct
>>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>>> give a clock that isn't adjusted by NTP.
>>
>> I thought we decided that NTP adjustment isn't an issue, because
>> it's always gradual.
>
> Well, in t
On Thu, Apr 5, 2012 at 00:45, Greg Ewing wrote:
> Lennart Regebro wrote:
>>
>> Since the only monotonic clock that can be adjusted by NTP is Linux'
>> CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
>> give a clock that isn't adjusted by NTP.
>
> I thought we decided that NTP a
On Thu, Apr 5, 2012 at 1:41 PM, Cameron Simpson wrote:
> It was pointed out (by Nick Coglan I think?) that if the system clock
> stepped backwards then a timeout would be extended by at least that
> long.
Guido pointed it out (it was in a reply to me, though).
Cheers,
Nick.
--
Nick Coghlan |
On 04Apr2012 22:23, PJ Eby wrote:
| On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote:
| > More details why it's hard to define such function and why I dropped
| > it from the PEP.
| >
| > If someone wants to propose again such function ("monotonic or
| > fallback to system" clock), two issues shoul
On Apr 4, 2012 7:28 PM, "Victor Stinner" wrote:
>
> More details why it's hard to define such function and why I dropped
> it from the PEP.
>
> If someone wants to propose again such function ("monotonic or
> fallback to system" clock), two issues should be solved:
>
> - name of the function
> -
Lennart Regebro wrote:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP.
I thought we decided that NTP adjustment isn't an issue, because
it's always gradual.
--
Greg
> I failed to propose a consistent and clear API because I (and Guido!) wanted
> to fallback to the system clock. Falling back to the system clock is a
> problem when you have to define the function in the documentation or if you
> don't want to use the system clock (but do something else) if no mo
On 2012-04-03, at 9:28 PM, Victor Stinner wrote:
> In the last version of my PEP, time.monotonic() is simply defined as "a
> monotonic clock (cannot go backward)". There is no more "... best ..." in its
> definition.
I like the last version of the PEP ;)
-
Yury
I am fine with the PEP as it is now (2012-04-04 15:34 GMT).
A question:
Since the only monotonic clock that can be adjusted by NTP is Linux'
CLOCK_MONOTONIC, if we avoid it, then time.monotonic() would always
give a clock that isn't adjusted by NTP. That would however mean we
wouldn't support mon
> I failed to propose a consistent and clear API because I (and Guido!) wanted
> to fallback to the system clock. Falling back to the system clock is a
> problem when you have to define the function in the documentation or if you
> don't want to use the system clock (but do something else) if no mo
>> Why does it already have these things when the PEP is not accepted?
>> ...
>> (This is not a rhetorical question, perhaps there is a good reason why
>> these have been added independently of the PEP.)
time.clock_gettime() & friends were added by the issue #10278. The
function was added before s
On Wed, 4 Apr 2012 18:09:40 +1000
Steven D'Aprano wrote:
> > Python 3.3 has already time.clock_gettime() and time.clock_getres() with
> > CLOCK_REALTIME, CLOCK_MONOTONIC, CLOCK_MONOTONIC_RAW, CLOCK_HIGHRES.
>
> Why does it already have these things when the PEP is not accepted?
>
> (This is no
On Wed, Apr 04, 2012 at 03:28:34AM +0200, Victor Stinner wrote:
> Le 04/04/2012 02:33, Steven D'Aprano a écrit :
> >Judging by the hundreds of emails regarding PEP 418, the disagreements
> >about APIs, namings, and even what characteristics clocks should have, I
> >believe that the suggestion is to
Lock it in before the paint dries.
On Apr 4, 2012 10:05 AM, "Matt Joiner" wrote:
> Finally! We've come full circle.
>
> +1 for monotonic as just described by Victor.
>
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/list
Finally! We've come full circle.
+1 for monotonic as just described by Victor.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40
On 2012-04-03, at 8:33 PM, Steven D'Aprano wrote:
> 1) the os module should expose lightweight wrappers around whatever clocks
> the operating system provides;
+1. That should make it flexible enough to those who really need it.
> 2) the time module should NOT provide any further clocks other
Le 04/04/2012 02:33, Steven D'Aprano a écrit :
Judging by the hundreds of emails regarding PEP 418, the disagreements
about APIs, namings, and even what characteristics clocks should have, I
believe that the suggestion is too divisive (and confusing!) to be
accepted or rejected at this time.
Oh
On Wed, Apr 4, 2012 at 10:33 AM, Steven D'Aprano wrote:
> Python has worked pretty well without high res and monotonic clocks for 20
> years. Let's not rush into a suboptimal design based on who can outlast
> everyone else in this discussion.
+1
FWIW, I'd be fine with underscore prefixes on *any
52 matches
Mail list logo
