Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On Fri, Apr 6, 2012 at 11:32 PM, Victor Stinner victor.stin...@gmail.com wrote: On Linux, I now prefer to use CLOCK_MONOTONIC (monotonic) than CLOCK_MONOTONIC_RAW (monotonic and steady as defined by C++) *because* its frequency is adjusted. I don't think that's a reason that should be considered. There just doesn't seem to be a single best clock, nor do clocks of similar character seem to be easy to find across platforms. So the reasons I'd like to see are of the form we should provide CLOCK_MONOTONIC on Linux as one of our small selection of recommended clocks *because* the frequency adjustment makes it *most* useful in use-cases A and B, and it's a *reasonable* choice in use-case C *but* we need to document that it's a terrible choice for use-case D. Why do I ask for this kind of argument? Because there are only a few people (you, Glyph, Zooko) who seem to have studied clocks closely enough to be able to evaluate the technical issues involved in *this* clock is good/mediocre/unusable in *that* use case. I'm happy to leave such judgments up to you guys. What the rest of us can contribute is (a) use cases to consider and (b) our opinions on the relative importance of various use cases in whether we should recommend a particular clock (ie, provide a named API in the stdlib for it). ___ 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
Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.
Hi Andrew, On Thu, Apr 05, 2012 at 11:16:54PM +0300, Andrew Svetlov wrote: I tried to: andrew@tiktaalik2 ~/projects hg clone ssh://h...@hg.python.org/cpython ssh://h...@hg.python.org/sandbox/tkdocs repo created, public URL is http://hg.python.org/sandbox/tkdocs abort: clone from remote to remote not supported You could do the server side clone using the web form here - http://hg.python.org/cpython/ Then you could you that repo to work on your stuff. Thanks, Senthil ___ 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
Re: [Python-Dev] Pep 393 and debugging
I wonder if there is a way to make this situation easier? Perhaps for debug builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function? I'd like to stress Benjamin's recommendation. Dave Malcolm's gdb extensions (requires gdb with Python support) are really powerful; they will automatically render PyObject* by displaying the actual logical value (and not just for strings). Failing that, I use _PyObject_Dump to display strings; this requires a debugger that can call functions in the debuggee (like gdb). Regards, Martin ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On Sat, Apr 7, 2012 at 8:47 AM, Victor Stinner victor.stin...@gmail.com wrote: Objects of class steady_clock represent clocks for which values of time_point advance at a steady rate relative to real time. That is, the clock may not be adjusted. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady I don't understand this definition. All clocks have a clock drift. [[...]] you can use a NTP daemon to adjust automatically using a free farm of atomic clocks distributed around the world. That's inside the black box; C++ doesn't care about *how* the clock is made to be steady by the system. The system could incorporate an atomic clock, or it could use NTP to keep the clock closely corresponding to physical time. The C++ program doesn't ask, and the system shouldn't tell. So you can get a cheap steady clock if you accept that (OMG!) it can be adjusted. Or did I misunderstand the clock may not be adjusted? I think you are not keeping your context consistent with the viewpoint of the C++ committee. To the C++ committee, a steady clock may be expected to just keep ticking as far as the C++ program is concerned. What this means is that the clock value is incremented in sequence: it never goes backward, and it never jumps over a possible time value. How closely that ticking approximates physical time is Somebody Else's Problem; C++ simply assumes that it does. In other words, a clock adjustment in the C++ standard means that the clock's reported time values occur out of sequence. However, if the intervals between clock ticks are adjusted by NTP (or by a little old Swiss watchmaker moving the pendulum bob) in order to improve its steadiness (ie, accurate correspondence to physical time), C++ doesn't know about that, and doesn't care. Amusingly enough, various people's statements about common usage of monotonic notwithstanding, C++'s definition of monotonic was mathematically monotonic. Cf. N3092, 20.10.1. (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3092.pdf) Regards, ___ 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
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
2012/4/7 Janzert janz...@janzert.com: On 4/5/2012 6:32 AM, Victor Stinner wrote: I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two reads of the CLOCK_MONOTONIC clock is a result in *seconds*, whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or smaller than a second. time.monotonic() unit is the second, as written in its documentation. I believe the above is only true for sufficiently large time deltas. One of the major purposes of NTP slewing is to give up some short term accuracy in order to achieve long term accuracy (e.g. whenever the clock is found to be ahead of real time it is purposefully ticked slower than real time). I don't think that NTP works like that. NTP only uses very smooth adjustements: slewing: change the clock frequency to be slightly faster or slower (which is done with adjtime()). Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize. http://www.python.org/dev/peps/pep-0418/#ntp-adjustment So for benchmarking it would not be surprising to be better off with the non-adjusted clock. Ideally there would be a clock that was slewed just enough to try and achieve short term accuracy, but I don't know of anything providing that. time.monotonic() is not written for benchmarks. It does not have the highest frequecency, it's primary property is that is monotonic. A side effect is that it is usually the steadiest clock. For example, on Windows time.monotonic() has only an accuracy of 15 ms (15 milliseconds not 15 microseconds). If you consider that the PEP should also solve the issue of benchmarking clock, we should continue the work on this section: http://www.python.org/dev/peps/pep-0418/#deferred-api-time-perf-counter Victor ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On 7 April 2012 09:12, Stephen J. Turnbull step...@xemacs.org wrote: I don't think that's a reason that should be considered. There just doesn't seem to be a single best clock, nor do clocks of similar character seem to be easy to find across platforms. So the reasons I'd like to see are of the form we should provide CLOCK_MONOTONIC on Linux as one of our small selection of recommended clocks *because* the frequency adjustment makes it *most* useful in use-cases A and B, and it's a *reasonable* choice in use-case C *but* we need to document that it's a terrible choice for use-case D. From the PEP: Use cases: Display the current time to a human (e.g. display a calendar or draw a wall clock): use system clock, i.e. time.time() or datetime.datetime.now(). Event scheduler, timeout: time.monotonic(). Benchmark, profiling: time.clock() on Windows, time.monotonic(), or fallback to time.time() Functions To fulfill the use cases, the functions' properties are: time.time(): system clock, wall clock. time.monotonic(): monotonic clock time.get_clock_info(name): get information on the specified time function That broadly covers it, I'd say. There are 2 main exceptions I see: (1) your suggestion of explain why clock X is a terrible choice for use case Y isn't there, although I'm not sure how important that is, and (2) there's no really good cross-platform option given for benchmarking/profiling (time.clock() is fine on Windows, but it gives CPU time on Unix - is that acceptable?) Also, Victor - you missed time.clock() from Functions. Was that deliberate because it's sometimes CPU time? Maybe it should be added for clarity? Paul. ___ 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
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
Victor Stinner wrote: 2012/4/7 Janzert janz...@janzert.com: On 4/5/2012 6:32 AM, Victor Stinner wrote: I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two reads of the CLOCK_MONOTONIC clock is a result in *seconds*, whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or smaller than a second. time.monotonic() unit is the second, as written in its documentation. I believe the above is only true for sufficiently large time deltas. One of the major purposes of NTP slewing is to give up some short term accuracy in order to achieve long term accuracy (e.g. whenever the clock is found to be ahead of real time it is purposefully ticked slower than real time). I don't think that NTP works like that. NTP only uses very smooth adjustements: slewing: change the clock frequency to be slightly faster or slower (which is done with adjtime()). Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize. http://www.python.org/dev/peps/pep-0418/#ntp-adjustment That is incorrect. NTP by default will only slew the clock for small discrepancies. For large discrepancies, it will step the clock, causing the time to jump. By default, large here means more than 128 milliseconds. Yes, milliseconds. http://www.ntp.org/ntpfaq/NTP-s-config-tricks.htm#AEN4249 In any case, NTP is not the only thing that adjusts the clock, e.g. the operating system will adjust the time for daylight savings. -- Steven ___ 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
Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.
Thank you. That works. Is there way to delete unused repo? On Sat, Apr 7, 2012 at 11:20 AM, Senthil Kumaran sent...@uthcode.com wrote: Hi Andrew, On Thu, Apr 05, 2012 at 11:16:54PM +0300, Andrew Svetlov wrote: I tried to: andrew@tiktaalik2 ~/projects hg clone ssh://h...@hg.python.org/cpython ssh://h...@hg.python.org/sandbox/tkdocs repo created, public URL is http://hg.python.org/sandbox/tkdocs abort: clone from remote to remote not supported You could do the server side clone using the web form here - http://hg.python.org/cpython/ Then you could you that repo to work on your stuff. Thanks, Senthil -- Thanks, Andrew Svetlov ___ 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
Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.
On Sat, 07 Apr 2012 15:15:00 +0300, Andrew Svetlov andrew.svet...@gmail.com wrote: Thank you. That works. Is there way to delete unused repo? This is what I've heard: If a repo isn't used (at all) it eventually gets deleted automatically. Otherwise, you have to ask. Probably python-committers is the best place for a delete request. If this becomes a burden at some point, someone will figure out a secure way to automate it...security is the reason it isn't automated now. --David ___ 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
Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.
Andrew, when you prepare the tkinter documentation, I advise you to include a link to www.tkdocs.com -- probably the best resource in this way (at least it was very useful for me). Maybe even should offer these guys do official documentation, if they agree and if there would be no conflict of interests (they offer commercial e-book). ___ 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
Re: [Python-Dev] cpython: Issue #3033: Add displayof parameter to tkinter font.
On Sat, Apr 7, 2012 at 5:06 PM, Serhiy Storchaka storch...@gmail.com wrote: Andrew, when you prepare the tkinter documentation, I advise you to include a link to www.tkdocs.com -- probably the best resource in this way (at least it was very useful for me). Done in sanbox/tkdoc repo. -- Thanks, Andrew Svetlov ___ 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
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
2012/4/7 Steven D'Aprano st...@pearwood.info: Victor Stinner wrote: 2012/4/7 Janzert janz...@janzert.com: On 4/5/2012 6:32 AM, Victor Stinner wrote: I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two reads of the CLOCK_MONOTONIC clock is a result in *seconds*, whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or smaller than a second. time.monotonic() unit is the second, as written in its documentation. I believe the above is only true for sufficiently large time deltas. One of the major purposes of NTP slewing is to give up some short term accuracy in order to achieve long term accuracy (e.g. whenever the clock is found to be ahead of real time it is purposefully ticked slower than real time). I don't think that NTP works like that. NTP only uses very smooth adjustements: slewing: change the clock frequency to be slightly faster or slower (which is done with adjtime()). Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize. http://www.python.org/dev/peps/pep-0418/#ntp-adjustment That is incorrect. NTP by default will only slew the clock for small discrepancies. For large discrepancies, it will step the clock, causing the time to jump. By default, large here means more than 128 milliseconds. Yes, milliseconds. http://www.ntp.org/ntpfaq/NTP-s-config-tricks.htm#AEN4249 We are talking about CLOCK_MONOTONIC. Steping is disabled on this clock. Victor ___ 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
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On 07Apr2012 20:40, Steven D'Aprano st...@pearwood.info wrote: | Victor Stinner wrote: | I don't think that NTP works like that. NTP only uses very smooth adjustements: [...] | http://www.python.org/dev/peps/pep-0418/#ntp-adjustment | | That is incorrect. NTP by default will only slew the clock for small | discrepancies. For large discrepancies, it will step the clock, causing the | time to jump. By default, large here means more than 128 milliseconds. | Yes, milliseconds. | http://www.ntp.org/ntpfaq/NTP-s-config-tricks.htm#AEN4249 | | In any case, NTP is not the only thing that adjusts the clock, e.g. the | operating system will adjust the time for daylight savings. Ignoring the discussion of NTP, daylight saving is a _presentation_ issue. It is _display_. The OS clock does not change for daylight saving! Think: seconds since the epoch. This is a continuous function. Daylight saving presentation occurs turning a seconds-since-epoch into a human decomposed time (hours, etc). Now, AFAIR, Windows used to run its system clock in local time i.e. it did have to jump its clock for daylight saving. Hopefully that is long gone. UNIX never did this. It ran in seconds since the epoch (in its case, start of 01jan1970 GMT). Printing dates and timestamps to humans needed daylight saving knowledge etc. Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Stan Malyshev s...@netcom.com wrote: | You're dragging a peg in a blind hairpin when you see a patch of coolant | up ahead, and you hear the airbrakes of an oncoming 18-wheeler. | What do you do? WHAT DO YOU DO? (Speed, anyone?) Shoot my pillion? - Vociferous Mole stev...@starbase.neosoft.com ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On 07Apr2012 01:47, Victor Stinner victor.stin...@gmail.com wrote: | I don't understand this definition. All clocks have a clock drift. | This is just one exception: atomic clocks, but such clocks are rare | and very expensive. They've got drift too. It is generally very small. Anecdote: I used to keep my wristwatch (oh, the days of wrist watches:-) synched to an atomic clock. By walking 4 metres down the hall from my office to peer into the window of the room with the atomic clock:-) Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ Knox's 386 is slick.Fox in Sox, on Knox's Box Knox's box is very quick. Plays lots of LSL. He's sick! - Gregory Bond g...@bby.com.au, (Apologies to John Iron Bar Mackin.) ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On Apr 7, 2012, at 3:08 AM, Paul Moore wrote: Use cases: Display the current time to a human (e.g. display a calendar or draw a wall clock): use system clock, i.e. time.time() or datetime.datetime.now(). Event scheduler, timeout: time.monotonic(). Benchmark, profiling: time.clock() on Windows, time.monotonic(), or fallback to time.time() ISTM, an event scheduler should use time.time(). If I schedule an event at 9:30am exactly, I really want my system time to be one that is used. Stock traders, for example, need to initiate event based on scheduled times (i.e. the market opening and closing times). With respect to benchmarking, the important attribute of time keeping is that the start and end times be computed from the same offset. For that purpose, I would want a clock that wasn't subject to adjustment at all, or if it did adjust, do so in a way that doesn't hide the fact (i.e. spreading-out the adjustment over a number of ticks or freezing time until a negative adjustment had caught-up). Then, there are timeouts, a common use-case where I'm not clear on the relative merits of the different clocks. Which is the recommended clock for code like this? start = time.time() while event_not_occurred(): if time.time() - start = timeout: raise TimeOutException Ideally, the clock used here shouldn't get adjusted during the timing. Failing that, the system time (plain old time.time()) seems like a reasonable choice (I'm not used to seeing the system time just around at an irregular pace). If time gets set backwards, it is possible to add code to defend against that as long as the clock doesn't try to hide that time went backwards: start = time.time() while event_not_occurred(): now = time.time() if now start: # time went backwards, so restart the countdown start = now if now - start = timeout: raise TimeOutException If the new clocks go in (or rather stay in), there should be some clear recommendations about which ones to use for various use cases. Those recommendations need to be explained (i.e. under what circumstance would timeout code be better if one abandoned time.time() in favor of one of the new clocks). I ask this because adding multiple clocks WILL cause some confusion. There will be cases where different tools use different clocks, resulting in unexpected interactions. Victor is proposing that almost every use of time.time() in the standard library be replaced by monotonic, but I'm at a loss to explain whether the code would actually be better off or to explain in what circumstances the new code would behave differently in any observable way. AFAICT, there has never been a reported bug in sched or Queue because they used time.time(), so I'm reluctant to have those changed without very clear understanding of how the code would be better (i.e. what negative outcome would be avoided with time.monotonic or somesuch). Raymond ___ 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
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On Apr 7, 2012, at 3:40 AM, Steven D'Aprano wrote: In any case, NTP is not the only thing that adjusts the clock, e.g. the operating system will adjust the time for daylight savings. Daylight savings time is not a clock adjustment, at least not in the sense this thread has mostly been talking about the word clock. It doesn't affect the seconds from epoch measurement, it affects the way in which the clock is formatted to the user. -glyph___ 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
Re: [Python-Dev] Pep 393 and debugging
Thanks, _PyObject_Dump sounds like just the ticket. Most of the time, the VS2010 debugger can just run functions willie nillie and thing should simply work. Frá: Martin v. Löwis [mar...@v.loewis.de] Sent: 7. apríl 2012 09:08 To: Kristján Valur Jónsson Cc: python-dev@python.org Efni: Re: [Python-Dev] Pep 393 and debugging I wonder if there is a way to make this situation easier? Perhaps for debug builds, we can store some debug information in the frame object, e.g. utf8 encoding of the filename and function? I'd like to stress Benjamin's recommendation. Dave Malcolm's gdb extensions (requires gdb with Python support) are really powerful; they will automatically render PyObject* by displaying the actual logical value (and not just for strings). Failing that, I use _PyObject_Dump to display strings; this requires a debugger that can call functions in the debuggee (like gdb). Regards, Martin ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
Thank you for your veto. Still, again for the sake of keeping track of things and such, there is this: http://en.wikipedia.org/wiki/Wall_clock_time and also my original suggestion: http://bugs.python.org/issue10278 In the end, the world shall be ruled by the nomenclaturists. K Frá: python-dev-bounces+kristjan=ccpgames@python.org [python-dev-bounces+kristjan=ccpgames@python.org] fyrir hönd Guido van Rossum [gu...@python.org] Sent: 6. apríl 2012 15:42 To: Paul Moore Cc: Python-Dev Efni: Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed) I'd like to veto wall clock because to me that's the clock on my wall, i.e. local time. Otherwise I like the way this thread is going. --Guido van Rossum (sent from Android phone) On Apr 6, 2012 4:57 AM, Paul Moore p.f.mo...@gmail.commailto:p.f.mo...@gmail.com wrote: On 6 April 2012 11:12, Steven D'Aprano st...@pearwood.infomailto:st...@pearwood.info wrote: Glyph Lefkowitz wrote: On Apr 5, 2012, at 8:07 PM, Zooko Wilcox-O'Hearn wrote: 2. Those who think that monotonic clock means a clock that never jumps, and that runs at a rate approximating the rate of real time. This is a very useful kind of clock to have! It is what C++ now calls a steady clock. It is what all the major operating systems provide. All clocks run at a rate approximating the rate of real time. That is very close to the definition of the word clock in this context. All clocks have flaws in that approximation, and really those flaws are the whole point of access to distinct clock APIs. Different applications can cope with different flaws. I think that this is incorrect. py time.clock(); time.sleep(10); time.clock() 0.41 0.41 Blame Python's use of CPU time in clock() on Unix for that. On Windows: time.clock(); time.sleep(10); time.clock() 14.879754156329385 24.879591008462793 That''s a backward compatibility issue, though - I'd be arguing that time.clock() is the best name for normally the right clock for interval, benchmark or timeout uses as long as you don't care about oddities like suspend otherwise. Given that this name is taken, I'd argue for time.wallclock. I'm not familiar enough with the terminology to know what to expect from terms like monotonic, steady, raw and the like. Paul. ___ Python-Dev mailing list Python-Dev@python.orgmailto:Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
Just to clarify my previous post. It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP. I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis. For scheduling logic (such as the sched module), I would think that NTP adjusted time would be what you want. I'm also unclear on the interactions between components implemented with different clocks (for example, if my logs show three seconds between events and a 10-second time-out exception occurs, is that confusing)? Raymond ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
Victor et al,
Just an update note:
I've started marking up clocks with attributes; not yet complete and I
still need to make a small C extension to present the system clocks to
Python space (which means learning to do that, too).
But you can glance over the start on it here:
https://bitbucket.org/cameron_simpson/css/src/tip/lib/python/cs/clockutils.py
Several feature flags and some properties for qualifying clocks.
Still needed stuff includes: C access to clocks, .accuracy being actual
clock precision versus the resolution of the units in the underlying OS
call, a __repr__ and/or __str__ to decode feature bitmaps into useful
strings, .is_*() __getattr__ method to resolve against flags by name
or maybe has_flag(str), etc.
On 07Apr2012 01:16, Victor Stinner victor.stin...@gmail.com wrote:
| | This is the original reason for the original defect (issue 10278)
| | unix' clock() doesn't actually provide a clock in this sense,
| | it provides a resource usage metric.
|
| Yeah:-( Its help says Return the CPU time or real time since [...].
| Two very different things, as demonstrated. I suppose neither goes
| backwards, but this seems like a classic example of the useless
| monotonic clock against which Greg Ewing railed.
|
| And why? For one thing, because one can't inspect its metadata to find
| out what it does.
|
| Should I add another key to the result of
| time.get_clock_info('clock')? How can we define clock on Windows
| (almost monotonic and steady clock) vs clock on UNIX (CPU time) with
| a flag or a value?
For clocks I'm going with two feature flags: WALLCLOCK and RUNTIME. The
former indicates a clock that tries to stay in synch with real world time,
and would still advance when the system is suspended or idle; it would
almost certainly need to step over a suspend. The latter means system
run time; it accrues only while the system is up. Neither is CPU usage
(so a time.sleep(10) would add 10 seconds to both).
I think resource usage is not a clock. We could characterise such
timers and counters with a lot of the same metrics we like to use with
clocks, but I do not think they should be returned by a system
purporting to return clocks or clock values.
On 07Apr2012 14:22, I wrote:
| On 06Apr2012 17:30, Glenn Linderman v+pyt...@g.nevcal.com wrote:
| | Hopefully, for each system, the characteristics of each clock can be
| | discovered, and fully characterized in available metadata for the clock...
|
| Victor has asked me to do that for my skeleton, based on the tables he
| has assembled. I'll see what i can do there...
I've started on this, see above.
Victor Stinner victor.stin...@gmail.com wrote:
| | - define flags of all clocks listed in the PEP 418: clocks used in
| | the pseudo-code of time.steady and time.perf_counter, and maybe also
| | time.time
|
| I'll make one. It will take a little while. Will post again when ready.
So, new code to glance over as evidence of good faith, if not speed:-(
Cheers,
--
Cameron Simpson c...@zip.com.au DoD#743
http://www.cskk.ezoshosting.com/cs/
Life is uncertain. Eat dessert first. - Jim Blandy
___
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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger raymond.hettin...@gmail.com wrote: Just to clarify my previous post. It seems clear that benchmarking and timeout logic would benefit from a clock that cannot be adjusted by NTP. I'm unclear on whether time.sleep() will be based on the same clock so that timeouts and sleeps are on the same basis. I made the same suggestion earlier but I don't know that anyone did anything with it. :-( It would be nice to know what clock sleep() uses on each of the major platforms. For scheduling logic (such as the sched module), I would think that NTP adjusted time would be what you want. In my view, it depends on whether you are scheduling far in the future (presumably guided by a calendar) or a short time ahead (milliseconds to hours). I'm also unclear on the interactions between components implemented with different clocks (for example, if my logs show three seconds between events and a 10-second time-out exception occurs, is that confusing)? I don't think this is avoidable. The logs will always use time.time() or a local time derived from it; but we've accepted that for benchmarking, timeouts and short-interval scheduling, that's not a good clock to use. -- --Guido van Rossum (python.org/~guido) ___ 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
Re: [Python-Dev] this is why we shouldn't call it a monotonic clock (was: PEP 418 is too divisive and confusing and should be postponed)
On 07Apr2012 18:49, Guido van Rossum gu...@python.org wrote: | On Sat, Apr 7, 2012 at 6:26 PM, Raymond Hettinger | raymond.hettin...@gmail.com wrote: | Just to clarify my previous post. | It seems clear that benchmarking and timeout logic would benefit | from a clock that cannot be adjusted by NTP. Indeed. Except for calendar programs setting alarms:-) I suppose they wake up regularly and consult local time anyway. | I'm unclear on whether time.sleep() will be based on the same clock | so that timeouts and sleeps are on the same basis. | | I made the same suggestion earlier but I don't know that anyone did | anything with it. :-( It would be nice to know what clock sleep() uses | on each of the major platforms. I saw it but didn't know what I could do with it, or even if it can be found out in any very general sense. Looking at nanosleep(2) on a recent Linux system says: POSIX.1 specifies that nanosleep() should measure time against the CLOCK_REALTIME clock. However, Linux measures the time using the CLOCK_MONOTONIC clock. This probably does not matter, since the POSIX.1 specification for clock_settime(2) says that discontinuous changes in CLOCK_REALTIME should not affect nanosleep(): Setting the value of the CLOCK_REALTIME clock via clock_settime(2) shall have no effect on threads that are blocked waiting for a relative time service based upon this clock, including the nanosleep() function; ... Consequently, these time services shall expire when the requested relative interval elapses, independently of the new or old value of the clock. and POSIX's nanosleep(3p) says: ... except for the case of being interrupted by a signal, the suspension time shall not be less than the time specified by rqtp, as measured by the system clock CLOCK_REALTIME. | For scheduling logic (such as the sched module), I would think that | NTP adjusted time would be what you want. | | In my view, it depends on whether you are scheduling far in the future | (presumably guided by a calendar) or a short time ahead (milliseconds | to hours). In my view it depends on whether you're working in a calendar or in elapsed time. The scheduling range (far in the future for example) shouldn't be relevant, for all that far in the future is usually done with a calendar instead of a relative timespans in flat seconds. Raymond: | I'm also unclear on the interactions between components implemented with | different clocks (for example, if my logs show three seconds between | events and a 10-second time-out exception occurs, is that confusing)? I don't think it is confusing given some more context; to me it would usually be a Big Clue that the internal supposedly-wallclock got a big adjustment between log timestamps. If that shouldn't happen it may be confusing or surprising... Cheers, -- Cameron Simpson c...@zip.com.au DoD#743 http://www.cskk.ezoshosting.com/cs/ The street finds its own uses for things. - William Gibson ___ 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
