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
> -
On Thu, 05 Apr 2012 01:29:47 -, Python tracker
wrote:
>
> An unexpected error occurred during the processing
> of your message. The tracker administrator is being
> notified.
Since the bounce message went here, I'm posting this here for those who
are curious what caused it.
It was triggere
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
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path:
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org [82.94.164.166])
by ps
> 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 05Apr2012 08:50, Steven D'Aprano wrote:
| Although I don't like the get_clock() API, I don't think this argument
against
| it is a good one.
Just to divert briefly; you said in another post you didn't like the API
and (also/because?) it didn't help discoverability.
My core objective was to
2012/4/4 Lennart Regebro :
> On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote:
>> It depends if the option supports other values. But as I understood,
>> the keyword value must always be True.
>
> Or False, obviously. Which would also be default.
Ok for the default, but what happens if the call
On Wed, Apr 04, 2012 at 12:52:00PM -0700, Ethan Furman wrote:
> Oleg Broytman wrote:
> >On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
> >>Oleg Broytman wrote:
> >>> . Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is
> >>>
> >>>for flag in (THIS, THAT):
> >>> try:
> >
Oleg Broytman wrote:
On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
. Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise
On 04Apr2012 19:47, Georg Brandl wrote:
| Am 04.04.2012 18:18, schrieb Ethan Furman:
| > Lennart Regebro wrote:
| >> On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
| >>> What's unclear about returning None if no clocks match?
| >>
| >> Nothing, but having to check error values on return funct
Oleg Broytman wrote:
On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
Oleg Broytman wrote:
. Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is
for flag in (THIS, THAT):
try:
clock = get_clock(flag)
except:
pass
else:
break
else:
raise
On Wed, Apr 04, 2012 at 11:03:02AM -0700, Ethan Furman wrote:
> Oleg Broytman wrote:
> > . Pythonic equivalent of "get_clock(THIS) or get_clok(THAT)" is
> >
> >for flag in (THIS, THAT):
> >try:
> >clock = get_clock(flag)
> >except:
> >pass
> >else:
> >break
> >
Georg Brandl wrote:
Am 04.04.2012 18:18, schrieb Ethan Furman:
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Pytho
Oleg Broytman wrote:
On Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python
Am 04.04.2012 18:18, schrieb Ethan Furman:
> Lennart Regebro wrote:
>> On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
>>> What's unclear about returning None if no clocks match?
>>
>> Nothing, but having to check error values on return functions are not
>> what you typically do in Python. Usua
On Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote:
> On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
> > What's unclear about returning None if no clocks match?
>
> Nothing, but having to check error values on return functions are not
> what you typically do in Python. Usually, Py
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please do
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
On Tue, Apr 3, 2012 at 18:07, Ethan Furman wrote:
> What's unclear about returning None if no clocks match?
Nothing, but having to check error values on return functions are not
what you typically do in Python. Usually, Python functions that fail
raise an error. Please don't force Python users to
On Wed, Apr 4, 2012 at 13:04, Victor Stinner wrote:
> It depends if the option supports other values. But as I understood,
> the keyword value must always be True.
Or False, obviously. Which would also be default.
//Lennart
___
Python-Dev mailing list
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
On Wed, 4 Apr 2012 17:30:26 +0200
Lennart Regebro 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 jus
On Tue, Apr 3, 2012 at 23:14, Victor Stinner 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/pipermai
On Mon, Apr 2, 2012 at 08:58, Thomas Spura wrote:
> On Mon, Apr 2, 2012 at 2:54 PM, Stefan Behnel wrote:
> > Antoine Pitrou, 02.04.2012 13:50:
> >> On Sun, 1 Apr 2012 19:44:00 -0500
> >> Brian Curtin wrote:
> >>> On Sun, Apr 1, 2012 at 17:31, Matěj Cepl wrote:
> On 1.4.2012 23:46, Brian Curt
On Wed, Apr 4, 2012 at 9:04 PM, Victor Stinner wrote:
> 2012/4/4 Antoine Pitrou :
>> On Wed, 4 Apr 2012 02:02:12 +0200
>> Victor Stinner wrote:
>>> > Lennart Regebro wrote:
>>> >> Well, get_clock(monotonic=True, highres=True) would be a vast
>>> >> improvement over get_clock(MONOTONIC|HIRES).
>>>
> 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
2012/4/4 Antoine Pitrou :
> On Wed, 4 Apr 2012 02:02:12 +0200
> Victor Stinner wrote:
>> > Lennart Regebro wrote:
>> >> Well, get_clock(monotonic=True, highres=True) would be a vast
>> >> improvement over get_clock(MONOTONIC|HIRES).
>>
>> I don't like this keyword API because you have to use a mag
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, 4 Apr 2012 02:02:12 +0200
Victor Stinner wrote:
> > Lennart Regebro wrote:
> >> Well, get_clock(monotonic=True, highres=True) would be a vast
> >> improvement over get_clock(MONOTONIC|HIRES).
>
> I don't like this keyword API because you have to use a magically
> marker (True). Why True?
(Sorry, should have sent to the list).
On 4 April 2012 01:04, Greg Ewing wrote:
> Cameron Simpson wrote:
>>
>> People have been saying "hires" throughout the
>> threads I think, but I for one would be slightly happier with "highres".
>
>
> hirez?
What's wrong with high_resolution?
Paul
_
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
34 matches
Mail list logo
