On 27 March 2012 01:23, Scott Dial wrote:
> If you want to define new clocks, then I wish you would use the same
> definitions that C++0x is using. That is:
>
> system_clock = wall clock time
> monotonic_clock = always goes forward but can be adjusted
> steady_clock = always goes forward and ca
On Mar 26, 2012, at 10:26 PM, Zooko Wilcox-O'Hearn wrote:
> Note that the C++ standard deprecated monotonic_clock once they
> realized that there is absolutely no point in having a clock that
> jumps forward but not back, and that none of the operating systems
> implement such a thing -- instead t
On Mar 27, 2012, at 3:17 AM, Glyph wrote:
> I don't think they can fully fix it without kernel changes
I got really curious about this and went and did some research. With some
really platform-specific hackery on every platform, you can mostly figure it
out; completely on OS X and Windows, alt
Hi,
On Thu, Mar 22, 2012 at 3:13 PM, Terry Reedy wrote:
> My impression is that the original reason for PendingDeprecationWarning
> versus DeprecationWarning was to be off by default until the last release
> before removal. But having DeprecationWarnings on by default was found to be
> too obnoxi
Reading this discussion, my conclusion is that not only us are
confused, but everyone is. I think therefore, that the way forward is
to only expose underlying API functions, and pretty much have no
intelligence at all.
At a higher level, we have two different "desires" here. You may want
a monoton
RT
thx.
linker
___
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%40mail-archive.com
On Tue, Mar 27, 2012 at 7:03 PM, Lennart Regebro wrote:
> But a time.steady() that tries to get a "best case" doesn't make sense
> at this time, as apparently nobody knows what a best case is, or what
> it should be called, except that it should apparently not be called
> steady(). Since monotonic
Nick Coghlan wrote:
The 3.3 time module would then be left with three interfaces:
time.time() # Highest resolution timer available
time.monotonic() # I'm not yet convinced we need the "raw" parameter
but don't much mind either way
time.try_monotonic() # Monotonic is preferred, but non-monotonic
On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:
> time.try_monotonic() # Monotonic is preferred, but non-monotonic
> presents a tolerable risk
This function seems unnecessary. It's easy to implement it when
required in your application, hence I don't think it is worth
adding to the stdlib.
-
Yur
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
I replaced time.steady() by time.try_monotonic(). I misunderstood "may
not" in the C++ doc: I understood it as "it may be adjusted by NTP",
whereas it means "it cannot be adjusted". Sorry for the confusion.
> What is the utility of "strict=True"? If I wanted that mode of
> operation, then why would I not just try to use "time.monotonic()"
> directly?
I mentioned the strict=True API in the PEP just to list all
propositions, but the PEP only proposes time.monotonic() and
time.try_monotonic(), no the fl
> steady_clock:
>
> mac = mach_absolute_time
> posix = clock_gettime(CLOCK_MONOTONIC)
> win = QueryPerformanceCounter
I read that QueryPerformanceCounter is no so monotonic, and
GetTickCount is preferred. Is it true?
> high_resolution_clock:
>
> * = { steady_clock, if available
> syste
2012/3/27 Jeffrey Yasskin :
> FWIW, I'm not sure you're the right person to drive time PEPs.
I don't want to drive the PEP. Anyone is invited to contribute, as I
wrote in my first message.
I'm completing/rewriting the PEP with all comments.
Victor
___
Yury Selivanov wrote:
On 2012-03-27, at 9:23 AM, Nick Coghlan wrote:
time.try_monotonic() # Monotonic is preferred, but non-monotonic
presents a tolerable risk
This function seems unnecessary. It's easy to implement it when
required in your application, hence I don't think it is worth
adding
> The clock does jump forward when the system suspends. At least some
> existing implementations of steady_clock in C++ already have this problem,
> and I think they all might.
>
> Time with respect to power management state changes is something that the
> PEP should address fully, for each p
> That's simple clear and explicit: try_monotic() tries to use the
> monotic clock if it can, but falls back to time.time() rather than
> failing entirely if no monotonic clock is available.
I renamed time.steady() to time.try_monotonic() in the PEP. It's a
temporary name until we decide what to d
On 27/03/2012 18:45, Victor Stinner wrote:
[snip...]
Straying from that is only going to create confusion. Besides that, the
one use case for "time.steady()" that you give (benchmarking) is better
served by a clock that follows the C++0x definition.
I added a time.hires() clock to the PEP for t
> I renamed time.steady() to time.try_monotonic() in the PEP. It's a
> temporary name until we decide what to do with this function.
How about get rid of it?
Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value. Finding out that someth
On Mon, Mar 26, 2012 at 11:23 PM, Stephen J. Turnbull wrote:
> On Tue, Mar 27, 2012 at 1:35 AM, PJ Eby wrote:
> > On Sun, Mar 25, 2012 at 2:56 AM, Stephen J. Turnbull >
> > wrote:
> >>
> >> But since he's arguing the
> >> other end in the directory layout thread (where he says there are many
> >
On 27/03/2012 20:18, Matt Joiner wrote:
Also monotonic should either not exist if it's not available, or always
guarantee a (artificially) monotonic value.
What do you mean by "(artificially) monotonic value"? Should Python
workaround OS bugs by always returning the maximum value of the clock?
Upfront hosting (Izak Burger) is going to do a Debian upgrade of the bug
tracker machine "soon" (likely tomorrow). This may cause some outage,
since there is a lot of custom stuff on the machine which may
break with newer (Python) versions. I'll notify here when the upgrade
is complete.
Regards,
M
2012/3/27 guido.van.rossum :
> http://hg.python.org/peps/rev/b9f43fe69691
> changeset: 4152:b9f43fe69691
> user: Guido van Rossum
> date: Mon Mar 26 20:35:14 2012 -0700
> summary:
> Approve PEP 411.
> (...)
> -Status: Draft
> +Status: Approved
The pep0 module doesn't accept the "
Matt, we need the fallback behaviour in the stdlib so we can gracefully
degrade the stdlib's *own* timeout handling back to the 3.2 status quo when
there is no monotic clock available. It is *not* acceptable for the Python
3.3 stdlib to only work on platforms that provide a monotonic clock.
Since
Scott wrote:
<< The Boost implementation can be summarized as:
system_clock:
mac = gettimeofday
posix = clock_gettime(CLOCK_REALTIME)
win = GetSystemTimeAsFileTime
steady_clock:
mac = mach_absolute_time
posix = clock_gettime(CLOCK_MONOTONIC)
win = QueryPerformanceCounter
high_resolutio
PJ Eby wrote:
Really? I've been doing "dump the app in a directory" since 1998 or so
on various *nix platforms. And when distutils came along, I set up a
user-specific cfg to install in the same directory. ISTR a 5-line
pydistutils.cfg is sufficient to make everything go into to a particular
On Mar 28, 2012 8:38 AM, "Victor Stinner" wrote:
>
> Scott wrote:
>
> << The Boost implementation can be summarized as:
>
> system_clock:
>
> mac = gettimeofday
> posix = clock_gettime(CLOCK_REALTIME)
> win = GetSystemTimeAsFileTime
>
> steady_clock:
>
> mac = mach_absolute_time
> posix = clo
On Wed, Mar 28, 2012 at 4:45 AM, PJ Eby wrote:
> [ body { width: 65em; } ] won't work - it'll make the entire page
> that width, instead of just text paragraphs.
True (I realized that might be bad in many cases later -- should have
tested first rather than posting something random), but despite
On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner
wrote:
> If QueryPerformanceCounter() is monotonic, the API can be simplified to:
>
> * time.time() = system clock
> * time.monotonic() = monotonic clock
> * time.hires() = monotonic clock or fallback to system clock
>
> time.hires() definition i
On Tue, Mar 27, 2012 at 9:02 PM, Ethan Furman wrote:
> PJ Eby wrote:
>
>> Really? I've been doing "dump the app in a directory" since 1998 or so
>> on various *nix platforms. And when distutils came along, I set up a
>> user-specific cfg to install in the same directory. ISTR a 5-line
>> pydis
On 3/27/2012 8:36 PM, Victor Stinner wrote:
> Scott wrote:
> Scott> monotonic_clock = always goes forward but can be adjusted
> Scott> steady_clock = always goes forward and cannot be adjusted
>
> I don't know if the monotonic clock should be called time.monotonic() or
> time.steady(). The clock s
On 28.03.2012 06:45, Nick Coghlan wrote:
> On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner
> wrote:
>> If QueryPerformanceCounter() is monotonic, the API can be simplified to:
>>
>> * time.time() = system clock
>> * time.monotonic() = monotonic clock
>> * time.hires() = monotonic clock or fall
31 matches
Mail list logo
