Re: [Python-Dev] PEP 418: Add monotonic clock
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 the least bad. //Lennart ___ 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: Add monotonic clock
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 correctly, the most common use for this function is when to time things. It will give you the best source available for timers, but it doesn't guarantee that it is steady or monotonic or high resolution or anything. It is also not the time, as it's not reliable as a wall-clock. So, how about time.timer()? //Lennart ___ 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: Add monotonic clock
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 explicit that the purpose of the function is to measure intervals, rather identifying absolute points in time. Cheers, Nadeem ___ 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: Add monotonic clock
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 not do, so that's all good). That means I think the PEP is fine now, if we rename highres(). time.time() already gets the highest resolution clock it can. Hence a highres() is confusing as the name implies that it returns a higher resolution clock than time.time(). And the name does not in any way indicate that the returned clock might be monotonic. try_monotonic() seems the obvious choice, since that's what it actually does. //Lennart ___ 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: Add monotonic clock
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 only need to not use CLOCK_MONOTONIC (which the PEP psuedo-code indeed also does not do, so that's all good). Right on. That means I think the PEP is fine now, if we rename highres(). time.time() already gets the highest resolution clock it can. No, time.time() is the clock that can be mapped to and from civil time. (Adjustments by NTP and the user notwithstanding.) The other clocks have a variable epoch and do not necessarily tick with a constant rate (e.g. they may not tick at all while the system is suspended). Hence a highres() is confusing as the name implies that it returns a higher resolution clock than time.time(). And the name does not in any way indicate that the returned clock might be monotonic. try_monotonic() seems the obvious choice, since that's what it actually does. I am still unhappy with the two names, but I'm glad that we're this close. We need two new names; one for an OS-provided clock that is monotonic or steady or whatever you want to call it, but which may not exist on all systems (some platforms don't have it, some host may not have it even though the platform generally does have it). The other name is for a clock that's one or the other; it should be the OS-provided clock if it exists, otherwise time.time(). Most code should probably use this one, so perhaps its name should be the shorter one. C++ calls these steady_clock and high_resolution_clock, respectively. But it also calls the civil time clock system_clock, so perhaps we shouldn't feel to bound by it (except that we *shouldn't* call something steady if it isn't). I still think the name monotonic give the wrong impression; I would be happy calling it steady. 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 it gave: Big Ben, alarm, chroniker, chronograph, chronometer, digital watch, hourglass, metronome, pendulum, stopwatch, sundial, tattler, tick-tock, ticker, timekeeper, timemarker, timepiece, timer, turnip, watch I wonder if something with tick would work? (Even though it returns a float. :-) If all else fails, I'd go with turnip. -- --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] PEP 418: Add monotonic clock
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 looked in an online thesaurus and here's a list of what it gave: Big Ben, alarm, chroniker, chronograph, chronometer, digital watch, hourglass, metronome, pendulum, stopwatch, sundial, tattler, tick-tock, ticker, timekeeper, timemarker, timepiece, timer, turnip, watch I wonder if something with tick would work? (Even though it returns a float. :-) If all else fails, I'd go with turnip. We could call it alice[*]: sometimes it goes fast, sometimes it goes slow, sometimes it even goes backward, but it does try to tell you when you are late. --David [*] 'whiterabbit' would be more descriptive, but that's longer than turnip. ___ 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: Add monotonic clock
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 correctly) proposal of calling the OS function - '_monotonic', and a python wrapper - 'monotonic'? And one more question: what do you think about introducing a special check, that will ensure that our python implementation of 'monotonic', in case of fallback to 'time.time()', raises an exception if time suddenly goes backward? - Yury ___ 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: Add monotonic clock
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 it gave: 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? It is driving me slowly crazy every time I see it used as an abbreviation for high resolution. Big Ben, alarm, chroniker, chronograph, chronometer, digital watch, hourglass, metronome, pendulum, stopwatch, sundial, tattler, tick-tock, ticker, timekeeper, timemarker, timepiece, timer, turnip, watch I wonder if something with tick would work? (Even though it returns a float. :-) 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. -- 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] PEP 418: Add monotonic clock
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 dissonance. 'Hires' is also a very famous brand of root beer. Hi-res *really* needs the hyphen (or underscore equivalent). -- Terry Jan Reedy ___ 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: Add monotonic clock
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 me that means that time.hires() would give a high resolution version of time.time(). Ie, not monotonic, but wall clock. The question then is why time.time() doesn't give that resolution from the start. It seems to me we need three functions: One to get the wall clock, one to get a monotonic clock, and one that falls back if no monotonic clock is available. Both time.time() and time.monotonic() should give the highest resolution possible. As such, time.hires() seems pointless. //Lennart ___ 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: Add monotonic clock
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 can be adjusted by NTP, at least on Linux 2.6.28. I don't know if other clocks used by my time.monotonic() proposition can be adjusted or not. If I understand correctly, time.steady() cannot be implemented using CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted? Does it really matter if a monotonic speed is adjusted? You are right that CLOCK_MONOTONIC can be adjusted, so the Boost implementation is wrong. I'm not sure that CLOCK_MONOTONIC_RAW is right either due to suspend -- there doesn't appear to be a POSIX or Linux clock that is defined that meets the steady definition. I am not familiar enough with Windows or Mac to know for certain whether the Boost implementation has the correct behaviors either. With that in mind, it's certainly better that we just provide time.monotonic() for now. If platform support becomes available, then we can expose that as it becomes available in the future. In other words, at this time, I don't think time.steady() can be implemented faithfully for any platform so lets just not have it at all. 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. I can't imagine a scenario where you would ask for a monotonic clock and would rather have an error than have Python fill in the gap with an emulation. -- Scott Dial sc...@scottdial.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] PEP 418: Add monotonic clock
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 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 hires as it suggests it may be higher resolution than time.time() and that's completely the wrong idea. It's also a completely ugly name, since it's quite hard to figure out what it is supposed to stand for in the first place. Georg ___ 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: Add monotonic clock
* 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 hires as it suggests it may be higher resolution than time.time() and that's completely the wrong idea. Why would it be a wrong idea? On Windows, time.monotonic() frequency is at least 1 MHz (can be GHz if it uses your CPU TSC) whereas time.time() is only updated each millisecond at the best case (each 15 ms by default if I remember correctly). On UNIX, CLOCK_MONOTONIC has the same theorical resolution than CLOCK_REALTIME (1 nanosecond thanks to the timespec structure) and I expect the same accuracy. On Mac, I don't know if mach_absolute_time() is more or as accurate than time.time(). time.hires() uses time.monotonic() if available, so if time.monotonic() has an higher resolution than time.time(), time.hires() can also be called a high-resolution clock. In practice, time.monotonic() is available on all modern platforms. 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), I don't know any monotonic clock jumping forwards by arbitrarily large amounts. Linux can change CLOCK_MONOTONIC speed, but NTP doesn't jump. then we're back to being able to enforce monotonicity even if the underlying clock jumps backwards due to system clock adjustments. Do you know a monotonic clock that goes backward? If yes, Python might workaround the clock bug directly in time.monotonic(). But I would prefer to *not* workaround OS bugs. 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: Add monotonic clock
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. (...) You are right that CLOCK_MONOTONIC can be adjusted, so the Boost implementation is wrong. I'm not sure that CLOCK_MONOTONIC_RAW is right either due to suspend -- there doesn't appear to be a POSIX or Linux clock that is defined that meets the steady definition. The term adjusted should be clarified. A clock can be adjusted by setting its counter (e.g. setting the system date and time) or by changing temporary its frequency (to go faster or slower). Linux only adjusts CLOCK_MONOTONIC frequency but the clock is monotonic because it always goes forward. The monotonic property can be described as: t1=time.monotonic() t2=time.monotonic() assert t2 = t1 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. time.hires() is needed when the OS doesn't provide any monotonic clock and because time.monotonic() must not use the system clock (which can jump backward). 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 can't imagine a scenario where you would ask for a monotonic clock and would rather have an error than have Python fill in the gap with an emulation. Sorry, I don't understand what you mean with fill in the gap with an emulation. You would like to implement a monotonic clock based on the system 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: Add monotonic clock
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 by NTP, at least on Linux 2.6.28. (...) You are right that CLOCK_MONOTONIC can be adjusted, so the Boost implementation is wrong. I'm not sure that CLOCK_MONOTONIC_RAW is right either due to suspend -- there doesn't appear to be a POSIX or Linux clock that is defined that meets the steady definition. The term adjusted should be clarified. A clock can be adjusted by setting its counter (e.g. setting the system date and time) or by changing temporary its frequency (to go faster or slower). Linux only adjusts CLOCK_MONOTONIC frequency but the clock is monotonic because it always goes forward. The monotonic property can be described as: t1=time.monotonic() t2=time.monotonic() assert t2 = t1 I agree. The point I was making is that implication of steady is that (t2-t1) is the same (given that t2 and t1 occur in time at the same relative moments), which is a guarantee that I don't see any platform providing currently. Any clock that can be adjusted in any manner is not going to meet the steady criterion. 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 sympathize with this, but if the idea is that the Python stdlib should use time.monotonic() for scheduling, then it needs to always be available. Otherwise, we are not going to use it ourselves, and what sort of example is that to set? I can't imagine a scenario where you would ask for a monotonic clock and would rather have an error than have Python fill in the gap with an emulation. Sorry, I don't understand what you mean with fill in the gap with an emulation. You would like to implement a monotonic clock based on the system clock? If time.monotonic() is only sometimes available, then I don't see the added clock being anything more than an amusement. (In this case, I'd rather just use clock_gettime() and friends directly, because I have to be platform aware anyways.) What developers want is a timer that is useful for scheduling things to happen after predictable interval in the future, so we should give them that to the best of our ability. -- Scott Dial sc...@scottdial.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] PEP 418: Add monotonic clock
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 sympathize with this, but if the idea is that the Python stdlib should use time.monotonic() for scheduling, then it needs to always be available. Otherwise, we are not going to use it ourselves, and what sort of example is that to set? There is time.hires() if you need a monotonic clock with a fallback to the system 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: Add monotonic clock
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 * 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 hires as it suggests it may be higher resolution than time.time() and that's completely the wrong idea. It's also a completely ugly name, since it's quite hard to figure out what it is supposed to stand for in the first place. Precisely. I always read hires as the verb hires (as in he hires a car to go on holiday) rather than HIgh RESolution. -1 on hires, it's a horrible name. And misleading as well, because on Linux, it isn't any more high res than time.time(). +1 on Nick's suggestion of try_monotonic. It is clear and obvious and doesn't mislead. I don't have an opinion as to what the implementation of try_monotonic should be. Whether it should fall back to time.time, time.clock, or something else, I don't know. But it is a clear and obvious solution for the use-case of I prefer the monotonic clock, if it is available, otherwise I'll take my chances with a best-effect clock. -- 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] PEP 418: Add 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 ___ 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: Add monotonic clock
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.) monotonish. Thus honoring the Principle Of Least Monotonishment, //arry/ ___ 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: Add monotonic clock
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. It is clear and obvious and doesn't mislead. How about monotonicest. (No, this is not really a serious suggestion.) monotonish. Thus honoring the Principle Of Least Monotonishment, //arry/ __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** anacrolix%40gmail.comhttp://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.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] PEP 418: Add monotonic clock
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 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. It is clear and obvious and doesn't mislead. How about monotonicest. (No, this is not really a serious suggestion.) monotonish. Thus honoring the Principle Of Least Monotonishment, //arry/ __**_ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/**mailman/listinfo/python-devhttp://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/**mailman/options/python-dev/** anacrolix%40gmail.comhttp://mail.python.org/mailman/options/python-dev/anacrolix%40gmail.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/me%40jonathanfrench.net ___ 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: Add monotonic clock
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 documentation - what their typical accuracy is (barring jumps) - what they do when the civil time is made to jump (forward or back) by the user - how they are affected by small tweaks to the civil time by NTP - what they do if the system is suspended and resumed - whether they can be shared between processes running on the same machine - whether they may fail or be unsupported under some circumstances I have a feeling that if I saw such a table it would be much easier to decide. I assume much of this has already been said at one point in this thread, but it's impossible to have an overview at the moment. If someone has more questions they'd like to see answered please add to the list. -- --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] PEP 418: Add monotonic clock
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. If the OS monotonic clock is not monotonic, the OS should be fixed. I sympathize with this, but if the idea is that the Python stdlib should use time.monotonic() for scheduling, then it needs to always be available. Otherwise, we are not going to use it ourselves, and what sort of example is that to set? There is time.hires() if you need a monotonic clock with a fallback to the system clock. 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: def _make_monotic: try: # Use underlying system monotonic clock if we can return _monotonic except NameError: _tick = time() def monotic(): _new_tick = time() if _new_tick _tick: _tick = _new_tick return _tick monotonic = _make_monotonic() Monotonicity of the result is thus ensured, even when using time.time() as a fallback. If using the system monotonic clock to get greater precision is acceptable for an application, then forcing monotonicity shouldn't be a problem either. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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 _new_tick _tick: _tick = _new_tick return _tick monotonic = _make_monotonic() Monotonicity of the result is thus ensured, even when using time.time() as a fallback. 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. - Yury ___ 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: Add monotonic clock
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 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 sympathize with this, but if the idea is that the Python stdlib should use time.monotonic() for scheduling, then it needs to always be available. Otherwise, we are not going to use it ourselves, and what sort of example is that to set? There is time.hires() if you need a monotonic clock with a fallback to the system clock. 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: def _make_monotic: try: # Use underlying system monotonic clock if we can return _monotonic except NameError: _tick = time() def monotic(): _new_tick = time() if _new_tick _tick: _tick = _new_tick return _tick monotonic = _make_monotonic() Monotonicity of the result is thus ensured, even when using time.time() as a fallback. If using the system monotonic clock to get greater precision is acceptable for an application, then forcing monotonicity shouldn't be a problem either. That's a pretty obvious trick. But why don't the kernels do this if monotonicity is so important? I'm sure there are also downsides, e.g. if the clock is accidentally set forward by an hour and then back again, you wouldn't have a useful clock for an hour. And the cache is not shared between processes so different processes wouldn't see the same clock value (I presume that most of these clocks have state in the kernel that isn't bound to any particular process -- AFAIK only clock() does that, and only on Unixy systems). -- --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] PEP 418: Add monotonic clock
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 large amounts), I don't know any monotonic clock jumping forwards by arbitrarily large amounts. Linux can change CLOCK_MONOTONIC speed, but NTP doesn't jump. If I understood Glyph's explanation correctly, then if your application is running in a VM and the VM is getting its clock data from the underlying hypervisor, then suspending and resuming the VM may result in forward jumping of the monotonic clocks in the guest OS. I believe suspending and hibernating may cause similar problems for even a non-virtualised OS that is getting its time data from a real-time clock chip that keeps running even when the main CPU goes to sleep. (If I *misunderstood* Glyph's explanation, then he may have only been talking about the latter case) 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. The only complication is thread synchronisation, and the GIL (or a dedicated lock for Jython/IronPython) can deal with that. Steadiness, on the other hand, requires a real world time reference and is thus really the domain of specialised hardware like atomic clocks and GPS units rather than software that can be suspended and resumed later without changing its internal state. There's a reason comms station operators pay substantial chunks of money for time frequency reference devices [1]. This is why I now think we only need one new clock function: time.monotonic(). It will be the system monotonic clock if one is available, otherwise it will be our own equivalent wrapper around time.time() that just caches the last value returned to ensure the result never goes backwards. With time.monotonic() guaranteed to always be available, there's no need for a separate function that falls back to an unconditioned time.time() result. Regards, Nick. [1] For example: http://www.symmetricom.com/products/gps-solutions/gps-time-frequency-receivers/XLi/ -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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 same value for an indefinite period, and may jump forwards by arbitrarily large amounts), I don't know any monotonic clock jumping forwards by arbitrarily large amounts. Linux can change CLOCK_MONOTONIC speed, but NTP doesn't jump. If I understood Glyph's explanation correctly, then if your application is running in a VM and the VM is getting its clock data from the underlying hypervisor, then suspending and resuming the VM may result in forward jumping of the monotonic clocks in the guest OS. I believe suspending and hibernating may cause similar problems for even a non-virtualised OS that is getting its time data from a real-time clock chip that keeps running even when the main CPU goes to sleep. (If I *misunderstood* Glyph's explanation, then he may have only been talking about the latter case) 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. The only complication is thread synchronisation, and the GIL (or a dedicated lock for Jython/IronPython) can deal with that. Steadiness, on the other hand, requires a real world time reference and is thus really the domain of specialised hardware like atomic clocks and GPS units rather than software that can be suspended and resumed later without changing its internal state. There's a reason comms station operators pay substantial chunks of money for time frequency reference devices [1]. This is why I now think we only need one new clock function: time.monotonic(). It will be the system monotonic clock if one is available, otherwise it will be our own equivalent wrapper around time.time() that just caches the last value returned to ensure the result never goes backwards. 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 anomaly, and if you are using timeouts, retries are already part of life. With time.monotonic() guaranteed to always be available, there's no need for a separate function that falls back to an unconditioned time.time() result. I would love to have only one new clock function in 3.3. Regards, Nick. [1] For example: http://www.symmetricom.com/products/gps-solutions/gps-time-frequency-receivers/XLi/ -- --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] PEP 418: Add monotonic clock
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 alternative here: falling back to an *unconditioned* time.time() value (which is the status quo, and necessary to preserve backwards compatibility). That will break just as badly in that scenario and is precisely the reason that the OS level monotonic functionality is desirable in the first place. I'd be quite happy with a solution that made the OS level monotonic clock part of the public API, with the caveat that it may not be available. Then the necessary trio of functions would be: time.time(): existing system clock, always available time.os_monotonic(): OS level monotonic clock, not always available time.monotonic(): always available, same as os_monotonic if it exists, otherwise uses a time() based emulation that may not be consistent across processes and may mark time for extended periods if the underlying OS clock is forced to jump back a long way. I think that naming scheme is more elegant than using monotonic() for the OS level monotonicity and try_monotonic() for the fallback version, but I'd be OK with the latter approach, too. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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. Time may jump back and forth, and with your approach it will result in monotonic() being completely unusable. If time jumps back for N minutes, or years, that leads to completely broken expectations for timeouts for N minutes or years correspondingly (and that's just the timeouts case, I'm sure that there are much more critical time-related use-cases.) If monotonic() will utilize such hack, you add nothing usable in stdlib. Every serious framework or library will have to re-implement it using only OS-level functions, and *FAIL* if the OS doesn't support monotonic time. Fail, because such framework can't guarantee that it will work correctly. So I think time module should have only one new function: monotonic(), and this function should be only available if OS provides the underlying functionality. No need for steady(), try_monotonic() and other hacks. Each module can decide if its dependancy on monotonic is critical or not, and if it is not, you can always have: try: from time import monotonic as _time except ImportError: from time import time as _time That's how lots of code is written these days, like using 'epoll' if available, and fallback to 'select' if not. Why don't you try to abstract differences between them in the standard library? So I see no point in adding some loose abstractions to the stdlib now. - Yury ___ 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: Add monotonic clock
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 OS-level functionality. You have to keep in mind the alternative here: falling back to an *unconditioned* time.time() value (which is the status quo, and necessary to preserve backwards compatibility). That will break just as badly in that scenario and is precisely the reason that the OS level monotonic functionality is desirable in the first place. Well, my argumentation is that you either have some code that depends on monotonic time and can't work without it, or you have a code that can work with any time (and only precision matters). Maybe I'm wrong. I'd be quite happy with a solution that made the OS level monotonic clock part of the public API, with the caveat that it may not be available. Then the necessary trio of functions would be: time.time(): existing system clock, always available time.os_monotonic(): OS level monotonic clock, not always available time.monotonic(): always available, same as os_monotonic if it exists, otherwise uses a time() based emulation that may not be consistent across processes and may mark time for extended periods if the underlying OS clock is forced to jump back a long way. I still don't like this 'emulation' idea. Smells bad for standard lib. Big -1 on this approach. - Yury ___ 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: Add monotonic clock
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 affected by a clock anomaly, and if you are using timeouts, retries are already part of life. I agree caching doesn't solve the problems that are solved by an OS level monotonic clock, but falling back to an unmodifided time.time() result instead doesn't solve those problems either. Falling back to time.time() just gives you the status quo: time may jump forwards or backwards by an arbitrary amount between any two calls. Cached monotonicity just changes the anomalous modes to be time jumping forwards, or time standing still for an extended period of time. The only thing the caching provides is that it becomes a reasonable fallback for a function called time.monotonic() - it *is* a monotonic clock that meets the formal contract of the function, it's just nowhere near as good or effective as one the OS can provide. Forward jumping anomalies aren't as harmful, are very hard to detect in the first place and behave the same regardless of the presence of caching, so the interesting case to look at is the difference in failure modes when the system clock jumps backwards. For benchmarking, a caching clock will produce a zero result instead of a negative result. Zeros aren't quite as obviously broken as negative numbers when benchmarking, but they're still sufficiently suspicious that most benchmarking activities will flag them as anomalous. If the jump back was sufficiently small that the subsequent call still produces a higher value than the original call, then behaviour reverts to being identical. For timeouts, setting the clock back means your operation will take longer to time out than you expected. This problem will occur regardless of whether you were using cached monotonicity (such that time stands still) or the system clock (such that time actually goes backwards). In either case, your deadline will never be reached until the backwards jump has been cancelled out by the subsequent passage of time. I want the standard library to be able to replace its time.time() calls with time.monotonic(). The only way we can do that without breaking cross-platform compatibility is if time.monotonic() is guaranteed to exist, even when the platform only provides time.time(). A dumb caching fallback implementation based on time.time() is the easiest way to achieve that withou making a complete mockery of the monotonic() name. There is then a *different* use case, which is 3.3+ only code which wants to fail noisily when there's no OS level monotonic support - the application developer really does want to fail *immediately* if there's no OS level monotonic clock available, instead of crossing your fingers and hoping you don't hit a clock adjustment glitch (crossing your fingers has, I'll point out, been the *only* option for all previous versions of Python, so it clearly can't be *that* scary a prospect). So, rather than making time.monotonic() something that the *standard library can't use*, I'd prefer to address that second use case by exposing the OS level monotonic clock as time.os_monotonic() only when it's available. That way, the natural transition for old time.time() based code is to time.monotonic() (with no cross-platform support implications), but time.os_monotonic() also becomes available for the stricter use cases. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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 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: falling back to an *unconditioned* time.time() value (which is the status quo, and necessary to preserve backwards compatibility). That will break just as badly in that scenario and is precisely the reason that the OS level monotonic functionality is desirable in the first place. Well, my argumentation is that you either have some code that depends on monotonic time and can't work without it, or you have a code that can work with any time (and only precision matters). Maybe I'm wrong. You're wrong. The primary use case for the new time.monotonic() function is to replace *existing* uses of time.time() in the standard library (mostly related to timeouts) that are currently vulnerable to clock adjustment related bugs. This real, concrete use case has been lost in some of the abstract theoretical discussions that have been going on this thread. We can't lose sight of the fact that using a system clock that is vulnerable to clock adjustment bugs to handle timeouts and benchmarking in Python has worked just fine for 20+ years. Using a monotonic clock instead is *better*, but it's far from essential, since clock adjustments that are big enough and poorly timed enough to cause real problems are fortunately a very rare occurrence. 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 available on every platform that currently provides time.time()*. This is why Victor's original proposal was that time.monotonic() simply fall back to time.time() if there was no OS level monotonic clock available. The intended use cases are using time.time() *right now* and have been doing so for years, so it is clearly an acceptable fallback for those cases. People (rightly, in my opinion) objected to the idea of time.monotonic() failing to guarantee monotonicity, thus the proposal to enforce at least a basic level of monotonicity through caching of the last returned value. I agree completely that this dumb caching solution doesn't solve any of the original problems with time.time() that make a time.monotonic() function desirable, but it isn't meant to. It's only meant to provide graceful degradation to something that is *no worse than the current behaviour when using time.time() in Python 3.2* while still respecting the property of monotonicity for the new API. Yes, it's an ugly hack, but it is a necessary fallback to avoid accidental regressions in our cross-platform support. For the major platforms (i.e. *nix, Mac OS X, Windows), there *will* be an OS level monotonic clock available, thus using time.monotonic() will have the desired effect of protecting from clocks being adjusted backwards. For other platforms, the behaviour (and vulnerabilities) will be essentially unchanged from the Python 3.2 approach (i.e. using time.time() with no monotonicity guarantees at all). However, some 3.3+ applications may want to be stricter about their behaviour and either bail out completely or fall back to an unfiltered time.time() call if an OS-level monotonic clock is not available. For those, it makes sense to expose time.os_monotonic() directly (and only if it is available), thus allowing those developers to make up their own mind instead of accepting the cross-platform fallback in time.monotonic(). Yes, you can get the exact same effect with the monotonic() and try_monotonic() naming scheme, but why force the standard library (and anyone else wanting to upgrade from time.time() without harming cross-platform support) to use such an ugly name when the os_monotonic and monotonic naming scheme provides a much neater alternative? Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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 benchmarking you just have to throw away a bad result that happened to be affected by a clock anomaly, and if you are using timeouts, retries are already part of life. I agree caching doesn't solve the problems that are solved by an OS level monotonic clock, but falling back to an unmodifided time.time() result instead doesn't solve those problems either. Falling back to time.time() just gives you the status quo: time may jump forwards or backwards by an arbitrary amount between any two calls. Cached monotonicity just changes the anomalous modes to be time jumping forwards, or time standing still for an extended period of time. The only thing the caching provides is that it becomes a reasonable fallback for a function called time.monotonic() - it *is* a monotonic clock that meets the formal contract of the function, it's just nowhere near as good or effective as one the OS can provide. TBH, I don't think like this focus on monotonicity as the most important feature. Forward jumping anomalies aren't as harmful, are very hard to detect in the first place and behave the same regardless of the presence of caching, so the interesting case to look at is the difference in failure modes when the system clock jumps backwards. Agreed. For benchmarking, a caching clock will produce a zero result instead of a negative result. Zeros aren't quite as obviously broken as negative numbers when benchmarking, but they're still sufficiently suspicious that most benchmarking activities will flag them as anomalous. If the jump back was sufficiently small that the subsequent call still produces a higher value than the original call, then behaviour reverts to being identical. So for benchmarking we don't care about jumps, really, and the caching version is slightly less useful. For timeouts, setting the clock back means your operation will take longer to time out than you expected. This problem will occur regardless of whether you were using cached monotonicity (such that time stands still) or the system clock (such that time actually goes backwards). In either case, your deadline will never be reached until the backwards jump has been cancelled out by the subsequent passage of time. Where in the stdlib do we actually calculate timeouts instead of using the timeouts built into the OS (e.g. select())? I think it would be nice if we could somehow use the *same* clock as the OS uses to implement timeouts. I want the standard library to be able to replace its time.time() calls with time.monotonic(). Where in the stdlib? (I'm aware of threading.py. Any other places?) The only way we can do that without breaking cross-platform compatibility is if time.monotonic() is guaranteed to exist, even when the platform only provides time.time(). A dumb caching fallback implementation based on time.time() is the easiest way to achieve that withou making a complete mockery of the monotonic() name. Yeah, so maybe it's a bad name. :-) There is then a *different* use case, which is 3.3+ only code which wants to fail noisily when there's no OS level monotonic support - the application developer really does want to fail *immediately* if there's no OS level monotonic clock available, instead of crossing your fingers and hoping you don't hit a clock adjustment glitch (crossing your fingers has, I'll point out, been the *only* option for all previous versions of Python, so it clearly can't be *that* scary a prospect). So, rather than making time.monotonic() something that the *standard library can't use*, I'd prefer to address that second use case by exposing the OS level monotonic clock as time.os_monotonic() only when it's available. That way, the natural transition for old time.time() based code is to time.monotonic() (with no cross-platform support implications), but time.os_monotonic() also becomes available for the stricter use cases. I'd be happier if the fallback function didn't try to guarantee things the underlying clock can't guarantee. I.e. I like the idea of having a function that uses some accurate OS clock if one exists but falls back to time.time() if not; I don't like the idea of that new function trying to interpret the value of time.time() in any way. Applications that need the OS clock's guarantees can call it directly. We could also offer something where you can introspect the properties of the clock (or clocks) so that an app can choose the best clock depending on its needs. To summarize my problem with the caching idea: take a simple timeout loop such as found in several places in threading.py. def wait_for(delta, eps): # Wait for delta seconds, sleeping eps seconds at a time
Re: [Python-Dev] PEP 418: Add monotonic clock
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 that retrieves it for Linux. ___ 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: Add monotonic clock
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 caching clock, and consider that the system clock made a jump backwards *before* this function is called. The cache prevents us from seeing it, so the initial call to now() returns the highest clock value seen so far. And until the system clock has caught up with that, now() will return the same value over and over -- so WE STILL WAIT TOO LONG. Ouch. OK, I'm convinced the caching fallback is worse than just falling back to time.time() directly, which means the naming problem needs to be handled another way. My conclusion: you can't win this game by forcing the clock to return a monotonic value. A better approach might be to compute how many sleep(eps) calls we're expected to make, and to limit the loop to that -- although sleep() doesn't make any guarantees either about sleeping too short or too long. Basically, if you do sleep(1) and find that your clock didn't move (enough), you can't tell the difference between a short sleep and a clock that jumped back. And if your clock moved to much, you still don't know if the problem was with sleep() or with your clock. With your point about the problem with the naive caching mechanism acknowledged, I think we can safely assign time.monotonic() as the name of the OS provided monotonic clock. 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. I don't like Victor's current hires (because it doesn't hint at the fallback behaviour, may actually be the same res as time.time() and reads like an unrelated English word). My own suggestion of try_monotic() would get the job done, but is hardly going to win any API beauty contests. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: Add monotonic clock
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 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 can get access to it, so call that time._time(). ___ 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: Add monotonic clock
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 returning a long stream of constant values when the system clock jumps backwards a significant amount: class MockTime: def __init__(self): self.ticks = [1, 2, 3, 4, 2, 3, 4, 5, 7, 3, 4, 6, 7, 8, 8, 9] self.i = -1 def __call__(self): self.i += 1 return self.ticks[self.i] time = MockTime() _prev = _prev_raw = 0 def monotonic(): global _prev, _prev_raw raw = time() delta = max(0, raw - _prev_raw) _prev_raw = raw _prev += delta return _prev And in use: [monotonic() for i in range(16)] [1, 2, 3, 4, 4, 5, 6, 7, 9, 9, 10, 12, 13, 14, 14, 15] Time: [1, 2, 3, 4, 2, 3, 4, 5, 7, 3, 4, 6, 7, 8, 8, 9] Nick: [1, 2, 3, 4, 4, 4, 4, 5, 7, 7, 7, 7, 7, 8, 8, 9] Mine: [1, 2, 3, 4, 4, 5, 6, 7, 9, 9, 10, 12, 13, 14, 14, 15] Mine will get ahead of the system clock each time it jumps back, but it's a lot closer to the ideal of a *strictly* monotonically increasing clock. Assuming that the system clock will never jump backwards twice in a row, the double-caching version will never have more than two constant values in a row. -- 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] PEP 418: Add monotonic clock
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 PEP. //Lennart ___ 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: Add monotonic clock
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 can get access to it, so call that time._time(). I'm not sure I understand your suggestion correctly, but replacing time.time() by time.monotonic() with fallback won't work, because time.monotonic() isn't wall-clock time: it can very well use an arbitrary reference point (most likely system start-up time). As for the hires() function, since there's no guarantee whatsoever that it does provide a better resolution than time.time(), this would be really misleading IMHO. ___ 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: Add monotonic clock
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 available on every
platform that currently provides time.time()*.
OK. I got your point. And also I've just realized what I dislike about
the way you want to implement the fallback. The main problem is that
I treat the situation when time jumps backward as an exception, because,
again, if you have timeouts you may get those timeouts to never be
executed. So let's make the try_monotonic() function (or whatever
name will be chosen) this way (your original code edited):
def _make_monotic():
try:
# Use underlying system monotonic clock if we can
return _monotonic
except NameError:
_tick = time()
def monotic():
nonlocal _time
_new_tick = time()
if _new_tick = _tick:
raise RuntimeError('time was adjusted backward')
_tick = _new_tick
return _new_tick
return monotonic
try_monotonic = _make_monotonic()
At least this approach tries to follow some of the python's zen.
-
Yury
___
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: Add monotonic clock
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 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: Add monotonic clock
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/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: Add monotonic clock
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 expedient of saving the last returned value: That's a pretty obvious trick. But why don't the kernels do this if monotonicity is so important? I'm sure there are also downsides, e.g. if the clock is accidentally set forward by an hour and then back again, you wouldn't have a useful clock for an hour. And the cache is not shared between processes so different processes wouldn't see the same clock value (I presume that most of these clocks have state in the kernel that isn't bound to any particular process -- AFAIK only clock() does that, and only on Unixy systems). What makes you think that isn't already true? I don't know what platforms that CPython compiles for that *won't* have one of the aforementioned functions available that provide a *real* monotonic clock. Surely, any platform that doesn't didn't recognize the need for it, or they would just provide a monotonic clock. That is to say, if you are a POSIX compliant system, then there is no reason to break gettimeofday() and friends when you can just implement CLOCK_MONOTONIC proper (even if it's just a trick like Nick's). 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. -- Scott Dial sc...@scottdial.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] PEP 418: Add monotonic 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. 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. 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: Add monotonic clock
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. Windows, Mac OS X, Solaris, and UNIX (CLOCK_MONOTONIC friends) provide monotonic clocks. I don't know any platform without monotonic 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: Add monotonic clock
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, we can easily coerce time.time() into being a monotonic clock by the simple expedient of saving the last returned value: That's a pretty obvious trick. But why don't the kernels do this if monotonicity is so important? I'm sure there are also downsides, e.g. if the clock is accidentally set forward by an hour and then back again, you wouldn't have a useful clock for an hour. And the cache is not shared between processes so different processes wouldn't see the same clock value (I presume that most of these clocks have state in the kernel that isn't bound to any particular process -- AFAIK only clock() does that, and only on Unixy systems). What makes you think that isn't already true? What does that refer to in this sentence? I don't know what platforms that CPython compiles for that *won't* have one of the aforementioned functions available that provide a *real* monotonic clock. Surely, any platform that doesn't didn't recognize the need for it, or they would just provide a monotonic clock. That is to say, if you are a POSIX compliant system, then there is no reason to break gettimeofday() and friends when you can just implement CLOCK_MONOTONIC proper (even if it's just a trick like Nick's). 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. -- Scott Dial sc...@scottdial.com -- --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] PEP 418: Add monotonic clock
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 and _threading.Lock.acquire() implement such retry loop using the system clock. They should use a monotonic clock instead. I think it would be nice if we could somehow use the *same* clock as the OS uses to implement timeouts. On Linux, nanosleep() uses CLOCK_MONOTONIC whereas POSIX suggests CLOCK_REALTIME. Some functions allow to choose the clock, like pthread locks or clock_nanosleep(). I'd be happier if the fallback function didn't try to guarantee things the underlying clock can't guarantee. I.e. I like the idea of having a function that uses some accurate OS clock if one exists but falls back to time.time() if not; I don't like the idea of that new function trying to interpret the value of time.time() in any way. We may workaround some OS known bugs like: http://support.microsoft.com/?id=274323 The link contains an example how to workaround the bug. The idea of the workaround is to use two different monotonic clocks to detect leaps, with one trusted clock (GetTickCount) and one untrusted clock having an higher resolution (QueryPerformanceCounter). I don't think that the same algorithm is applicable on other OSes because other OSes usually only provide one monotonic clock, sometimes though different API. 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: Add monotonic clock
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) - what they do when the civil time is made to jump (forward or back) by the user - how they are affected by small tweaks to the civil time by NTP - what they do if the system is suspended and resumed - whether they can be shared between processes running on the same machine - whether they may fail or be unsupported under some circumstances I have a feeling that if I saw such a table it would be much easier to decide. I assume much of this has already been said at one point in this thread, but it's impossible to have an overview at the moment. I don't know where I can get all these information, but I'm completing the PEP each time that I find a new information. It's difficult to get the accuracy of a clock and how it handles system suspend. I'm intereted if anyone has such information. 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: Add monotonic clock
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 discussion and the Decimal/datetime representation PEP. The main things required to be a PEP champion are passion and a willingness to listen to expert feedback and change course in response. If someone lacks the former, they will lose steam and their PEP will eventually be abandoned. If they don't listen to expert feedback, then their PEP will ultimately be rejected (sometimes a PEP will be rejected anyway as a poor fit for the language *despite* being responsive to feedback, but that's no slight to the PEP author). Victor has shown himself to be quite capable of handling those aspects of the PEP process, and the topics he has recently applied himself to are ones where it is worthwhile having a good answer in the standard library for Python 3.3. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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 = always goes forward and cannot be adjusted high_resolution_clock = steady_clock || system_clock +1. This seems like an ideal case for following prior art in designing a Python API. 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: Add monotonic 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 all implement a clock which doesn't jump in either direction. This is why I don't like the C++ terminology, because it seems to me that the C++ standard makes incorrect assertions about platform behavior, and apparently they standardized it without actually checking on platform capabilities. 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. I don't think they can fully fix it without kernel changes, either. On linux, see discussion of a possible CLOCK_BOOTTIME in the future. The only current way I know of to figure out how long the system has been asleep is to look at the wall clock and compare, and we've already gone over the problems with relying on the wall clock. Plus, libstdc++ gives you no portable way to get informed about system power management events, so you can't fix it even if you know about this problem, natch. Time with respect to power management state changes is something that the PEP should address fully, for each platform. On the other hand, hopefully you aren't controlling your python-based CNC laser welder from a laptop that you are closing the lid on while the beam is in operation. Not that the PEP shouldn't address it, but maybe it should just address it to say you're on your own and refer to a few platform-specific resources for correcting this type of discrepancy. (https://developer.apple.com/library/mac/#qa/qa1340/_index.html, http://msdn.microsoft.com/en-us/library/aa394362.aspx, http://upower.freedesktop.org/docs/UPower.html#UPower::Sleeping). -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 418: Add monotonic clock
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, although (as far as I can tell) only partially on Linux and FreeBSD. I'm not sure if it's possible to make use of these facilities without a Twisted-style event-loop though. If anybody's interested, I recorded the results of my research in a comment on the Twisted ticket for this: http://twistedmatrix.com/trac/ticket/2424#comment:26. -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 418: Add monotonic clock
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 monotonic clock, or you may not care. You may want high resolution, or you might not care. Which one is more important is something only you know. Therefore, we must have, at the minimum, a function that returns the highest resolution monotonic clock possible, as well as a function that returns the highest resolution system/wall clock possible. We also need ways to figure out what the resolution is of these clocks. In addition to that, you may have the requirement that the monotonic clock also should not be able to jump forward, but if I understand things correctly, most current OS's will not guarantee this. You may also have the requirement that the clock not only does not jump forward, but that it doesn't go faster or slower. Some clock implementations will speed up or slow down the monotonic clock, without jumps, to sync up with the wall clock. It seems only Unix provides a monotonic clock (CLOCK_MONOTONIC_RAW) that does not get adjusted at all. Now between all these requirements, only you know which one is more important? Do you primarily want a raw monotonic clock, and secondarily high resolution, or is the resolution more important than it being monotonic? (Because if you need a high resolution, you are usually measuring small timeframes, and the clock is more unlikely to be adjusted, for example). Since there is no obvious A is better than B that is better than C we first of all have to expose the underlying API's somehow, to allow people to make their own decisions. Secondly, since apparently not only python-dev, but many others as well, are a bit confused on this complex issue, I'm not sure we can provide any high-level functions that makes a best choice. As such the proposed time.monotonic() to get the monotonic clock on the various systems makes a lot of sense to me. It should get the highest resolution available on the system. Get GetTickCount64() of available on Windows, else GetTickCount(). The function could have a raw=False parameter to select between clock_gettime(CLOCK_MONOTONIC) and clock_gettime(CLOCK_MONOTONIC_RAW) on Unix, and it would get mach_absolute_time() on OS X. If no monotonic clock is available, it should raise an error.The same if you pass in raw=True and there is no monotonic clock that has no adjustments available. In the same vein, time.time() should provide the highest resolution system clock/wall clock available. We also need functions or attributes to get the resolution of these clocks. 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() raises an error if there is no monotonic clock available, implementing your own fallback is trivial in any case. //Lennart ___ 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: Add monotonic clock
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(). Since monotonic() raises an error if there is no monotonic clock available, implementing your own fallback is trivial in any case. +1 from me to Lennart's suggestion of mostly just exposing time.monotonic() without trying to get too clever. Applications that need a truly precise time source should *never* be reading it from the host OS (one fairly good solution can be to read your time directly from an attached GPS device). However, I think Victor's right to point out that the *standard library* needs to have a fallback to maintain backwards compatibility if time.monotonic() isn't available, and it seems silly to implement the same fallback logic in every module where we manipulate timeouts. As I concur with others that time.steady() is a thoroughly misleading name for this concept, I suggest we encapsulate the time.monotic if available, time.time otherwise handling as a time.try_monotic() function. 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. This is essential for backwards compatibility when migrating any current use of time.time() over to time.monotic(). Yes the monotonic clock is *better* for many use cases (including timeouts), but you'll usually be OK with the non-monotonic clock, too (particularly if that's what you were using anyway in earlier versions). After all, we've survived this long using time.time() for our timeout calculations, and bugs associated with clock adjustments are a rather rare occurrence. Third party libraries that need to support earlier Python versions can then implementation their own fallback logic (since they couldn't rely on time.try_monotonic being available either). 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 presents a tolerable risk Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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: Add monotonic clock
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 presents a tolerable risk +1 ~Ethan~ ___ 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: Add monotonic clock
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 ___ 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: Add monotonic clock
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 a time.hires() clock because time.monotonic() and time.try_monotonic() are not the best clocks for profiling or benchmarking. For example, on Windows, time.hires() uses QueryPerformanceCounter() whereas time.monotonic() and time.try_monotonic() uses GetTickCount[64](). I added the pseudo-code of each function. I hope that it is easier to understand than a long text. 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: Add monotonic clock
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 API. At worst, it generates an AttributeError (although that is not clear from your PEP). I tried to mention when a function is always available or not always available. Is it better in the last version of the PEP? 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 I tried to follow these names in the PEP. I don't propose steady_clock because I don't see exactly which clocks would be used to implement it, nor if we need to provide monotonic *and* steady clocks. What do you think? 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 the benchmarking/profiling use case. This function is not always available and so a program has to fallback manually to another clock. I don't think that it is an issue: Python programs already have to choose between time.clock() and time.time() depending on the OS (e.g. timeit module and pybench program). As well, certain kinds of scheduling/timeouts would be better implemented with the C++0x definition for steady rather than the monotonic one and vice-versa. Sorry, I don't understand. Which kind of scheduling/timeouts? The PEP is still a draft (work-in-progress). 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: Add monotonic clock
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, otherwise }
On Windows, I propose to use QueryPerformanceCounter() for
time.hires() and GetTickCount() for time.monotonic().
See the PEP for other OSes.
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: Add monotonic 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 ___ 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: Add monotonic clock
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 to the stdlib. If I understood Nick correctly, time.try_monotonic() is /for/ the stdlib. If others want to make use of it, fine. If others want to make their own fallback mechanism, also fine. ~Ethan~ ___ 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: Add monotonic clock
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 platform. I don't think that Python should workaround OS issues, but document them correctly. I started with this sentence for time.monotonic(): The monotonic clock may stop while the system is suspended. I don't know exactly how clocks behave with system suspend. Tell me if you have more information. (https://developer.apple.com/library/mac/#qa/qa1340/_index.html, http://msdn.microsoft.com/en-us/library/aa394362.aspx, http://upower.freedesktop.org/docs/UPower.html#UPower::Sleeping). I will read these links and maybe add them to the PEP. 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: Add monotonic clock
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 with this function. I also changed it to fallback to time.hires() if time.monotonic() is not available or failed. 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: Add monotonic clock
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 the benchmarking/profiling use case. This function is not always available and so a program has to fallback manually to another clock. I don't think that it is an issue: Python programs already have to choose between time.clock() and time.time() depending on the OS (e.g. timeit module and pybench program). It is this always-having-to-manually-fallback-depending-on-os that I was hoping your new functionality would avoid. Is time.try_monotonic() suitable for this usecase? Michael As well, certain kinds of scheduling/timeouts would be better implemented with the C++0x definition for steady rather than the monotonic one and vice-versa. Sorry, I don't understand. Which kind of scheduling/timeouts? The PEP is still a draft (work-in-progress). 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/fuzzyman%40voidspace.org.uk -- http://www.voidspace.org.uk/ May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html ___ 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: Add monotonic 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 something is already known to not work shouldn't require a call and a faked OSError. ___ 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: Add monotonic clock
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? Finding out that something is already known to not work shouldn't require a call and a faked OSError. What do you mean? time.monotonic() is not implemented if the OS doesn't provide any monotonic clock (e.g. if clock_gettime(CLOCK_MONOTONIC) is missing on UNIX). OSError is only raised when the OS returns an error. There is no such faked OSError. 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: Add monotonic 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 duplicating that logic in every module that handles timeouts would be silly, it makes sense to provide an obvious way to do it in the time module. -- Sent from my phone, thus the relative brevity :) ___ 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: Add monotonic clock
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_resolution_clock:
* = { steady_clock, if available
system_clock, otherwise }
I read again the doc of the QElapsedTimer class of the Qt library. So Qt
and Boost agree to say that QueryPerformanceCounter() *is* monotonic.
I was confused because of a bug found in 2006 in Windows XP on multicore
processors. QueryPerformanceCounter() gave a different value on each
core. The bug was fixed in Windows and is known as KB896256 (I already
added a link to the bug in the PEP).
I added a time.hires() clock to the PEP for the benchmarking/profiling
use case (...)
It is this always-having-to-manually-fallback-depending-on-os that I was
hoping your new functionality would avoid. Is time.try_monotonic()
suitable for this usecase?
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 is exactly what I was trying to implement with
time.steady(strict=True) / time.try_monotonic().
--
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.
I don't know if other clocks used by my time.monotonic() proposition can
be adjusted or not.
If I understand correctly, time.steady() cannot be implemented using
CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted?
Does it really matter if a monotonic speed is adjusted?
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: Add monotonic clock
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 = clock_gettime(CLOCK_MONOTONIC)
win = QueryPerformanceCounter
high_resolution_clock:
* = { steady_clock, if available
system_clock, otherwise }
I read again the doc of the QElapsedTimer class of the Qt library. So Qt
and Boost agree to say that QueryPerformanceCounter() *is* monotonic.
I was confused because of a bug found in 2006 in Windows XP on multicore
processors. QueryPerformanceCounter() gave a different value on each core.
The bug was fixed in Windows and is known as KB896256 (I already added a
link to the bug in the PEP).
I added a time.hires() clock to the PEP for the benchmarking/profiling
use case (...)
It is this always-having-to-manually-fallback-depending-on-os that I was
hoping your new functionality would avoid. Is time.try_monotonic()
suitable for this usecase?
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 is exactly what I was trying to implement with
time.steady(strict=True) / time.try_monotonic().
--
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.
Monotonic. It's still monotonic if it is adjusted forward, and that's okay.
I don't know if other clocks used by my time.monotonic() proposition can
be adjusted or not.
If I understand correctly, time.steady() cannot be implemented using
CLOCK_MONOTONIC on Linux because CLOCK_MONOTONIC can be adjusted?
Does it really matter if a monotonic speed is adjusted?
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/anacrolix%40gmail.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] PEP 418: Add monotonic clock
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 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 hires as it suggests it may be higher resolution than time.time() and that's completely the wrong idea. 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), then we're back to being able to enforce monotonicity even if the underlying clock jumps backwards due to system clock adjustments. Specifically: time.time() = system clock time._monotonic() = system level monotonic clock (if it exists) time.monotonic() = clock based on either time._monotonic() (if available) or time.time() (if not) that enforces monotonicity of returned values. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
[Python-Dev] PEP 418: Add monotonic 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 ___ 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: Add monotonic clock
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. QueryPerformanceCounter() has a good resolution for benchmarking, but it is not monotonic and so GetTickCount64() would be used for time.steady(). GetTickCount64() is monotonic but has only a resolution of 1 millisecond. We might add a third new function which provides the most accurate clock with or without a known starting point. We cannot use QueryPerformanceCounter() to enhance time.time() resolution because it has an unknown starting point. 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: Add monotonic clock
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 is not steady by any acceptable definition. I cannot fathom the utility of this function other than as a function that provides an automatic fallback from time.monotonic(). More importantly: this definition of steady is in conflict with the C++0x definition of steady that is where you sourced this named from![1] time.steady(strict=False) falls back to another clock if no monotonic clock is not available or does not work, but it does never fail. As I say above, that is so far away from what steady implies that this is a misnomer. What you are describing is a best-effort clock, which sounds a lot more like the C++0x high resolution clock. time.steady(strict=True) raises OSError if monotonic clock fails or NotImplementedError if the system does not provide a monotonic clock 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? At worst, it generates an AttributeError (although that is not clear from your PEP). What is the use case for strict=True that is not covered by your time.monotonic()? 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 cannot be adjusted high_resolution_clock = steady_clock || system_clock 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. As well, certain kinds of scheduling/timeouts would be better implemented with the C++0x definition for steady rather than the monotonic one and vice-versa. Rather, it seems you have a particular use-case in mind and have settled on calling that a steady clock despite how it belies its name. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3128.html#time.clock.steady 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. -- Scott Dial sc...@scottdial.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] PEP 418: Add monotonic clock
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 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 all implement a clock which doesn't jump in either direction. http://stackoverflow.com/questions/6777278/what-is-the-rationale-for-renaming-monotonic-clock-to-steady-clock-in-chrono In other words, yes! +1! The C++ standards folks just went through the process that we're now going through, and if we do it right we'll end up at the same place they are: http://en.cppreference.com/w/cpp/chrono/system_clock system_clock represents the system-wide real time wall clock. It may not be monotonic: on most systems, the system time can be adjusted at any moment. It is the only clock that has the ability to map its time points to C time, and, therefore, to be displayed. steady_clock: monotonic clock that will never be adjusted high_resolution_clock: the clock with the shortest tick period available Note that we don't really have the option of providing a clock which is monotonic but not steady in the sense of can jump forward but not back. It is a misunderstanding (doubtless due to the confusing name monotonic) to think that such a thing is offered by the underlying platforms. We can choose to *call* it monotonic, following POSIX instead of calling it steady, following C++. Regards, Zooko ___ 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: Add monotonic clock
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/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418: Add monotonic clock
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 = GetSystemTimeAsFileTime
steady_clock:
mac = mach_absolute_time
posix = clock_gettime(CLOCK_MONOTONIC)
win = QueryPerformanceCounter
high_resolution_clock:
* = { steady_clock, if available
system_clock, otherwise }
Whether or not these implementations meet the specification is an
exercise left to the reader..
--
Scott Dial
sc...@scottdial.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] PEP 418: Add monotonic clock
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
Re: [Python-Dev] PEP 418: Add monotonic clock
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:32 PM, Victor Stinner victor.stin...@gmail.com wrote: 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 ___ 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/jyasskin%40gmail.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
