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 too
(Sorry, should have sent to the list).
On 4 April 2012 01:04, Greg Ewing greg.ew...@canterbury.ac.nz 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?
On Wed, 4 Apr 2012 02:02:12 +0200
Victor Stinner victor.stin...@gmail.com 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
On Wed, 4 Apr 2012 18:09:40 +1000
Steven D'Aprano st...@pearwood.info 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?
2012/4/4 Antoine Pitrou solip...@pitrou.net:
On Wed, 4 Apr 2012 02:02:12 +0200
Victor Stinner victor.stin...@gmail.com 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
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 someone
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
On Wed, Apr 4, 2012 at 9:04 PM, Victor Stinner victor.stin...@gmail.com wrote:
2012/4/4 Antoine Pitrou solip...@pitrou.net:
On Wed, 4 Apr 2012 02:02:12 +0200
Victor Stinner victor.stin...@gmail.com wrote:
Lennart Regebro wrote:
Well, get_clock(monotonic=True, highres=True) would be a vast
On Mon, Apr 2, 2012 at 08:58, Thomas Spura thomas.sp...@googlemail.comwrote:
On Mon, Apr 2, 2012 at 2:54 PM, Stefan Behnel stefan...@behnel.de 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 Tue, Apr 3, 2012 at 23:14, Victor Stinner victor.stin...@gmail.com 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:
On Wed, 4 Apr 2012 17:30:26 +0200
Lennart Regebro rege...@gmail.com 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
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
On Wed, Apr 4, 2012 at 13:04, Victor Stinner victor.stin...@gmail.com 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
___
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us 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
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
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us 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
On Wed, Apr 04, 2012 at 05:47:16PM +0200, Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us 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
Am 04.04.2012 18:18, schrieb Ethan Furman:
Lennart Regebro wrote:
On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us 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
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 et...@stoneleaf.us 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
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 et...@stoneleaf.us 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
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
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 g.bra...@gmx.net wrote:
| Am 04.04.2012 18:18, schrieb Ethan Furman:
| Lennart Regebro wrote:
| On Tue, Apr 3, 2012 at 18:07, Ethan Furman et...@stoneleaf.us wrote:
| What's unclear about returning None if no clocks match?
|
| Nothing, but having to check
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 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:
clock =
2012/4/4 Lennart Regebro rege...@gmail.com:
On Wed, Apr 4, 2012 at 13:04, Victor Stinner victor.stin...@gmail.com 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
On 05Apr2012 08:50, Steven D'Aprano st...@pearwood.info 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
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
An unexpected error occurred during the processing
of your message. The tracker administrator is being
notified.
Return-Path: python-dev@python.org
X-Original-To: rep...@bugs.python.org
Delivered-To: roundup+trac...@psf.upfronthosting.co.za
Received: from mail.python.org (mail.python.org
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.
--
On Thu, 05 Apr 2012 01:29:47 -, Python tracker
roundup-ad...@psf.upfronthosting.co.za 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
On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com 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
On 04Apr2012 22:23, PJ Eby p...@telecommunity.com wrote:
| On Apr 4, 2012 7:28 PM, Victor Stinner victor.stin...@gmail.com 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
|
On Thu, Apr 5, 2012 at 1:41 PM, Cameron Simpson c...@zip.com.au 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.
--
34 matches
Mail list logo
