On Sat, Mar 31, 2012 at 11:50, Nadeem Vawda wrote:
> Out of the big synonym list Guido posted, I rather like time.stopwatch() - it
> makes it more explicit that the purpose of the function is to measure
> intervals,
> rather identifying absolute points in time.
I guess it's the least bad.
//Len
On Sat, Mar 31, 2012 at 8:27 AM, Lennart Regebro wrote:
> So, how about time.timer()?
That seems like a bad idea; it would be too easy to confuse with (or misspell
as) time.time().
Out of the big synonym list Guido posted, I rather like time.stopwatch() - it
makes it more explicit that the purpo
On Sat, Mar 31, 2012 at 02:26, Steven D'Aprano wrote:
> Guido van Rossum wrote:
>> If all else fails, I'd go with turnip.
>
> I can't tell if you are being serious or not.
>
> For the record, "turnip" in this sense is archaic slang for a thick pocket
> watch.
If I understand this correctly, the m
On 3/30/2012 8:26 PM, Steven D'Aprano wrote:
"hires" is a real English word, the present tense verb for engaging the
service or labour of someone or something in return for payment, as in
"he hires a gardener to mow the lawn". Can we please eliminate it from
consideration
I agree. Heavy cognit
Guido van Rossum wrote:
But for the other, I'm still at a loss, and that name is the most
important one. We can't call it steady because it isn't always.
highres or hires sounds awkward; try_monotonic or try_steady are even
more awkward. I looked in an online thesaurus and here's a list of
what
On 2012-03-30, at 3:40 PM, Guido van Rossum wrote:
> I still think the name "monotonic" give the wrong impression; I would
> be happy calling it steady.
Simple google search comparison shows that people ask about 'monotonic'
clock in python, not 'steady'.
How about following Nick's (if I recall
On Fri, 30 Mar 2012 12:40:25 -0700, Guido van Rossum wrote:
> But for the other, I'm still at a loss, and that name is the most
> important one. We can't call it steady because it isn't always.
> highres or hires sounds awkward; try_monotonic or try_steady are even
> more awkward. I looked in an o
On Fri, Mar 30, 2012 at 12:01 PM, Lennart Regebro wrote:
> The overview of the different monotonic clocks was interesting,
> because only one of them is adjusted by NTP, and that's the unix
> CLOCK_MONOTONIC. Hence we don't need a raw=False flag, which I
> previously suggested, we only need to not
The overview of the different monotonic clocks was interesting,
because only one of them is adjusted by NTP, and that's the unix
CLOCK_MONOTONIC. Hence we don't need a raw=False flag, which I
previously suggested, we only need to not use CLOCK_MONOTONIC (which
the PEP psuedo-code indeed also does n
On Wed, Mar 28, 2012 at 23:40, Victor Stinner wrote:
>> Does this primarily give a high resolution clock, or primarily a
>> monotonic clock? That's not clear from either the name, or the PEP.
>
> I expect a better resolution from time.monotonic() than time.time().
Sure. And for me that means that
> Could you (with help from others who contributed) try to compile a table
> showing, for each platform (Windows/Mac/Linux/BSD) which clocks (or
> variations) we are considering, and for each of those:
>
> - a link for the reference documentation
> - what their typical accuracy is (barring jumps)
>
> Where in the stdlib do we actually calculate timeouts instead of using
> the timeouts built into the OS (e.g. select())?
At least in threading and queue modules. The common use case is to
retry a function with a timeout if the syscall was interrupted by a
signal (EINTR error). The socket module
On Wed, Mar 28, 2012 at 2:36 PM, Scott Dial
wrote:
> On 3/28/2012 10:29 AM, Guido van Rossum wrote:
>> On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan wrote:
>>> Completely unintuitive and unnecessary. With the GIL taking care of
>>> synchronisation issues, we can easily coerce time.time() into bei
> I think the PEP should enumerate what platforms that CPython supports
> that will not benefit from a real monotonic clock. I think the number of
> platforms will be such a minority that the emulation makes sense.
> Practicality beats purity, and all.
The PEP lists OS monotonic clocks by platform
> Does this primarily give a high resolution clock, or primarily a
> monotonic clock? That's not clear from either the name, or the PEP.
I expect a better resolution from time.monotonic() than time.time(). I
don't have exact numbers right now, but I began to document each OS
clock in the PEP.
Vic
On 3/28/2012 10:29 AM, Guido van Rossum wrote:
> On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan wrote:
>> Completely unintuitive and unnecessary. With the GIL taking care of
>> synchronisation issues, we can easily coerce time.time() into being a
>> monotonic clock by the simple expedient of saving
> I would love to have only one new clock function in 3.3.
I already added time.clock_gettime() to 3.3 :-)
Victor
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/m
On 2012-03-28, at 1:55 PM, Yury Selivanov wrote:
> nonlocal _time
nonlocal _tick
obviously.
P.S. And we can make it to raise an error after some N calls
to time() resulting in lesser time that is stored in the _tick
variable.
-
Yury
___
Python-Dev ma
On 2012-03-28, at 11:35 AM, Nick Coghlan wrote:
> So, the primary use case is that we want to replace many of the
> time.time() calls in the standard library with time.monotonic() calls.
> To avoid backwards compatibility problems in the cross-platform
> support, that means time.monotonic() *must b
> What's wrong with "time.time()" again? As documented in
> http://docs.python.org/py3k/library/time.html it makes no guarantees,
> and specifically there is *no* guarantee that it will ever behave
> *badly*. Of course, we'll have to guarantee that, if a
> badly-behaved clock is available, users
On Wed, Mar 28, 2012 at 12:56, Victor Stinner wrote:
> There is time.hires() if you need a monotonic clock with a fallback to
> the system clock.
Does this primarily give a high resolution clock, or primarily a
monotonic clock? That's not clear from either the name, or the PEP.
//Lennart
___
Nick Coghlan wrote:
Completely unintuitive and unnecessary. With the GIL taking care of
synchronisation issues, we can easily coerce time.time() into being a
monotonic clock by the simple expedient of saving the last returned
value:
[snip]
Here's a version that doesn't suffer from the flaw of
On Thu, Mar 29, 2012 at 1:14 AM, Nick Coghlan wrote:
> That means choosing a name for the version that falls back to time()
> if monotonic() isn't available so it can be safely substituted for
> time.time() without having to worry about platform compatibility
> implications.
What's wrong with "ti
Matt Joiner wrote:
time.timeout_clock?
Everyone knows what that will be for and we won't have to make silly
theoretical claims about its properties and expected uses.
I don't.
--
Steven
___
Python-Dev mailing list
Python-Dev@python.org
http://mail
On Thu, Mar 29, 2012 at 1:47 AM, Guido van Rossum wrote:
> Where in the stdlib? (I'm aware of threading.py. Any other places?)
Victor had at least one other example. multiprocessing, maybe? I
believe the test suite may still have a few instances as well.
> But now consider a caching clock, and c
time.timeout_clock?
Everyone knows what that will be for and we won't have to make silly
theoretical claims about its properties and expected uses.
If no one else looks before I next get to a PC I'll dig up the clock/timing
source used for select and friends, and find any corresponding syscall th
On Wed, Mar 28, 2012 at 8:08 AM, Nick Coghlan wrote:
> On Thu, Mar 29, 2012 at 12:42 AM, Guido van Rossum wrote:
>> As I said, I think the caching idea is bad. We may have to settle for
>> semantics that are less than perfect -- presumably if you are doing
>> benchmarking you just have to throw a
On Thu, Mar 29, 2012 at 1:02 AM, Yury Selivanov wrote:
> On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
>
>> On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
>> wrote:
>>> What if system time jumps 1 year back? We'll have the same
>>> monotonic time returned for this whole year?
>>>
>>> I don't
On Thu, Mar 29, 2012 at 12:42 AM, Guido van Rossum wrote:
> As I said, I think the caching idea is bad. We may have to settle for
> semantics that are less than perfect -- presumably if you are doing
> benchmarking you just have to throw away a bad result that happened to
> be affected by a clock
On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
> On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
> wrote:
>> What if system time jumps 1 year back? We'll have the same
>> monotonic time returned for this whole year?
>>
>> I don't think we should even try to emulate any of OS-level
>> function
On 2012-03-28, at 10:36 AM, Nick Coghlan wrote:
> Monotonicity is fairly easy to guarantee - you just remember the last
> value you returned and ensure you never return a lower value than that
> for the lifetime of the process.
As I said in my previous mail - I don't think we should ever do that.
On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
wrote:
> What if system time jumps 1 year back? We'll have the same
> monotonic time returned for this whole year?
>
> I don't think we should even try to emulate any of OS-level
> functionality.
You have to keep in mind the alternative here: fall
On Wed, Mar 28, 2012 at 7:36 AM, Nick Coghlan wrote:
> On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
> wrote:
>>> If we're simplifying the idea to only promising a monotonic
>>> clock (i.e. will never go backwards within a given process, but may
>>> produce the same value for an indefinite peri
On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
wrote:
>> If we're simplifying the idea to only promising a monotonic
>> clock (i.e. will never go backwards within a given process, but may
>> produce the same value for an indefinite period, and may jump forwards
>> by arbitrarily large amounts),
>
On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan wrote:
> On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
> wrote:
> In that case, I don't think time.try_monotonic() is really needed
> because we can emulate "time.monotonic()" in software if the platform is
> deficient.
As I wr
On 2012-03-28, at 10:17 AM, Nick Coghlan wrote:
> def _make_monotic:
> try:
> # Use underlying system monotonic clock if we can
> return _monotonic
> except NameError:
> _tick = time()
> def monotic():
> _new_tick = time()
>
On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
wrote:
In that case, I don't think time.try_monotonic() is really needed
because we can emulate "time.monotonic()" in software if the platform is
deficient.
>>>
>>> As I wrote, I don't think that Python should workaround OS bugs. If
>>
Victor,
I have completely lost track of the details of this discussion. Could
you (with help from others who contributed) try to compile a table
showing, for each platform (Windows/Mac/Linux/BSD) which clocks (or
variations) we are considering, and for each of those:
- a link for the reference do
No, that would be time.monotonous(). This is time.monotonic(), the function
that can only play a single note at a time. Uh, I mean time.monophonic().
Hmm, this is harder than it looks.
On 28 March 2012 14:48, Matt Joiner wrote:
> time.monotonic(): The uneventful and colorless function.
> On Mar
time.monotonic(): The uneventful and colorless function.
On Mar 28, 2012 9:30 PM, "Larry Hastings" wrote:
> On 03/28/2012 01:56 PM, R. David Murray wrote:
>
>> On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano
>> wrote:
>>
>>> +1 on Nick's suggestion of try_monotonic. It is clear and obvious a
On 03/28/2012 01:56 PM, R. David Murray wrote:
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
+1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
"monotonish".
Thus honor
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano wrote:
> +1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't
> mislead.
How about "monotonicest".
(No, this is not really a serious suggestion.)
However, time.steadiest might actually work.
--David
_
Georg Brandl wrote:
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 o
>>> In that case, I don't think time.try_monotonic() is really needed
>>> because we can emulate "time.monotonic()" in software if the platform is
>>> deficient.
>>
>> As I wrote, I don't think that Python should workaround OS bugs. If
>> the OS monotonic clock is not monotonic, the OS should be fi
On 3/28/2012 4:48 AM, Victor Stinner 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 speed c
>> 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 speed can be adjusted by NTP, at least on Linux
>> < 2.6
>> * time.time() = system clock
>> * time.monotonic() = monotonic clock
>> * time.hires() = monotonic clock or fallback to system clock
>>
>> time.hires() definition is exactly what I was trying to implement with
>> "time.steady(strict=True)" / "time.try_monotonic()".
>
> Please don't call the f
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
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 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 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
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
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
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?
> 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 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
> 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
> 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
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
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
___
> 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
> 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
> 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.
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
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 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
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
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
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 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 Tue, Mar 27, 2012 at 3:51 PM, Jeffrey Yasskin wrote:
> FWIW, I'm not sure you're the right person to drive time PEPs. You
> don't seem to have come into it with much knowledge of time, and it's
> taken several repetitions for you to take corrections into account in
> both this discussion and th
FWIW, I'm not sure you're the right person to drive time PEPs. You
don't seem to have come into it with much knowledge of time, and it's
taken several repetitions for you to take corrections into account in
both this discussion and the Decimal/datetime representation PEP.
On Mon, Mar 26, 2012 at 4
Cheers, that clears things up.
___
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 3/26/2012 10:59 PM, Matt Joiner wrote:
> So does anyone care to dig into the libstd++/boost/windoze
> implementation to see how they each did steady_clock?
The Boost implementation can be summarized as:
system_clock:
mac = gettimeofday
posix = clock_gettime(CLOCK_REALTIME)
win = GetSyst
So does anyone care to dig into the libstd++/boost/windoze implementation
to see how they each did steady_clock?
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mail
> system_clock = wall clock time
> monotonic_clock = always goes forward but can be adjusted
> steady_clock = always goes forward and cannot be adjusted
> high_resolution_clock = steady_clock || system_clock
Note that the C++ standard deprecated monotonic_clock once they
realized that there is
On 3/26/2012 7:32 PM, Victor Stinner wrote:
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
"""
time.steady
This clock advances at a steady rate relative to real time. It may be
adjusted.
"""
Please do not call this "steady". If the clock can be adjusted,
> I started to write the PEP 418 to clarify the notions of monotonic and
> steady clocks.
>
> The PEP is a draft and everyone is invited to contribute!
time.steady() doesn't fit the benchmarking use case: it looks like we
have to decide between stability and clock resolution.
QueryPerformanceCoun
Hi,
I started to write the PEP 418 to clarify the notions of monotonic and
steady clocks.
The PEP is a draft and everyone is invited to contribute!
http://www.python.org/dev/peps/pep-0418/
http://hg.python.org/peps/file/tip/pep-0418.txt
Victor
___
Pyt
79 matches
Mail list logo
