On Sat, Mar 31, 2012 at 11:50, Nadeem Vawda nadeem.va...@gmail.com 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
On Sat, Mar 31, 2012 at 02:26, Steven D'Aprano st...@pearwood.info 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
On Sat, Mar 31, 2012 at 8:27 AM, Lennart Regebro rege...@gmail.com 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
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
On Fri, Mar 30, 2012 at 12:01 PM, Lennart Regebro rege...@gmail.com 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
On Fri, 30 Mar 2012 12:40:25 -0700, Guido van Rossum gu...@python.org 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
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
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 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 cognitive
On Wed, Mar 28, 2012 at 23:40, Victor Stinner victor.stin...@gmail.com 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
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 speed
On 28.03.2012 06:45, Nick Coghlan wrote:
On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner
victor.stin...@gmail.com wrote:
If QueryPerformanceCounter() is monotonic, the API can be simplified to:
* time.time() = system clock
* time.monotonic() = monotonic clock
* time.hires() = monotonic
* 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 fallback version
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.28. (...)
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 can be adjusted
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 fixed.
I
Georg Brandl wrote:
On 28.03.2012 06:45, Nick Coghlan wrote:
On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner
victor.stin...@gmail.com wrote:
If QueryPerformanceCounter() is monotonic, the API can be simplified to:
* time.time() = system clock
* time.monotonic() = monotonic clock
*
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Aprano st...@pearwood.info 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
On 03/28/2012 01:56 PM, R. David Murray wrote:
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Apranost...@pearwood.info 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.)
time.monotonic(): The uneventful and colorless function.
On Mar 28, 2012 9:30 PM, Larry Hastings la...@hastings.org wrote:
On 03/28/2012 01:56 PM, R. David Murray wrote:
On Wed, 28 Mar 2012 23:05:59 +1100, Steven D'Apranost...@pearwood.info
wrote:
+1 on Nick's suggestion of try_monotonic.
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 anacro...@gmail.com wrote:
time.monotonic(): The uneventful and colorless
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
On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
victor.stin...@gmail.com 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.
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()
if
On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Mar 28, 2012 at 8:56 PM, Victor Stinner
victor.stin...@gmail.com 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
On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
victor.stin...@gmail.com 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
On Wed, Mar 28, 2012 at 7:36 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Wed, Mar 28, 2012 at 6:40 PM, Victor Stinner
victor.stin...@gmail.com 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
On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
yselivanov...@gmail.com 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
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 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
yselivanov...@gmail.com 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
On Thu, Mar 29, 2012 at 12:42 AM, Guido van Rossum gu...@python.org 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
On Thu, Mar 29, 2012 at 1:02 AM, Yury Selivanov yselivanov...@gmail.com wrote:
On 2012-03-28, at 10:45 AM, Nick Coghlan wrote:
On Thu, Mar 29, 2012 at 12:27 AM, Yury Selivanov
yselivanov...@gmail.com wrote:
What if system time jumps 1 year back? We'll have the same
monotonic time returned
On Wed, Mar 28, 2012 at 8:08 AM, Nick Coghlan ncogh...@gmail.com wrote:
On Thu, Mar 29, 2012 at 12:42 AM, Guido van Rossum gu...@python.org 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
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
On Thu, Mar 29, 2012 at 1:47 AM, Guido van Rossum gu...@python.org 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
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
On Thu, Mar 29, 2012 at 1:14 AM, Nick Coghlan ncogh...@gmail.com 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
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
On Wed, Mar 28, 2012 at 12:56, Victor Stinner victor.stin...@gmail.com 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
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*wink/. Of course, we'll have to guarantee that, if a
badly-behaved clock is available, users
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 be
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
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:
On 3/28/2012 10:29 AM, Guido van Rossum wrote:
On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan ncogh...@gmail.com 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
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.
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.
On Wed, Mar 28, 2012 at 2:36 PM, Scott Dial
scott+python-...@scottdial.com wrote:
On 3/28/2012 10:29 AM, Guido van Rossum wrote:
On Wed, Mar 28, 2012 at 7:17 AM, Nick Coghlan ncogh...@gmail.com wrote:
Completely unintuitive and unnecessary. With the GIL taking care of
synchronisation issues,
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
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)
-
On Tue, Mar 27, 2012 at 3:51 PM, Jeffrey Yasskin jyass...@gmail.com 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
On 27 March 2012 01:23, Scott Dial scott+python-...@scottdial.com 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 =
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 they
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,
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
On Tue, Mar 27, 2012 at 7:03 PM, Lennart Regebro rege...@gmail.com 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().
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.
-
Yury
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.
I added
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 flags
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
system_clock,
2012/3/27 Jeffrey Yasskin jyass...@gmail.com:
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
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
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 do
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
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
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?
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
On Mar 28, 2012 8:38 AM, Victor Stinner victor.stin...@gmail.com 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
On Wed, Mar 28, 2012 at 10:36 AM, Victor Stinner
victor.stin...@gmail.com 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
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
___
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.
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, then it
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
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:
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 =
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
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
79 matches
Mail list logo
