Re: [Python-Dev] Upgrading tcl/tk deps
> The Tk fix Terry refers is applicable only to the OS X Aqua Cocoa Tcl/Tk > 8.5 port. It has nothing to do with Windows, any other OS X Tcl/Tk, or > any other platform. Further, the Tcl/TK source Martin is talking about > is used only by the Windows installer builds. The python.org OS X > installers do not build or supply Tcl/Tk; they link with the > Apple-supplied Tcl/Tks and compatible distributions, like the > ActiveState ones. So this is all a non-issue. Thanks for the clarification. I was about to write something less polite. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] this is why we shouldn't call it a "monotonic clock" (was: PEP 418 is too divisive and confusing and should be postponed)
>> We're going around in circles. I'm not asking what sleep does, I want >> on principle a timer that does the same thing as sleep(), regardless >> of how sleep() works. So if on some OS sleep() uses the same algorithm >> as CLOCK_MONOTONIC_RAW, I want my timer to use that too. But if on >> some other OS sleep() uses CLOCK_MONOTONIC, I want my timer there to >> use that. And if on some OS sleep() is buggy and uses the time-of-day >> clock, well, I wouldn't mind if my timer used the same thing. > > sleep() takes a number of seconds as argument, so CLOCK_MONOTONIC > should be used, not CLOCK_MONOTONIC_RAW. If I understood correctly, > the unit of CLOCK_MONOTONIC is a second, whereas CLOCK_MONOTONIC_RAW > may be faster or slower than a second. sleep() is not affected by system clock update on any OS: I tested Linux, FreeBSD, Mac OS X and OpenIndiana. By the way, CLOCK_BOOTTIME was added to Linux 2.6.39: it includes time elapsed during system suspend, whereas CLOCK_MONOTONIC doesn't include time elapsed during system suspend. I updated the "Monotonic clocks" table to indicate if the clock includes the elapsed time or not. http://www.python.org/dev/peps/pep-0418/#monotonic-clocks Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
>> In any case, NTP is not the only thing that adjusts the clock, e.g. the >> operating system will adjust the time for daylight savings. > > Daylight savings time is not a clock adjustment, at least not in the sense > this thread has mostly been talking about the word "clock". It doesn't > affect the "seconds from epoch" measurement, it affects the way in which the > clock is formatted to the user. Ah yes, you're right. The system clock uses the UTC time zone on Linux and Windows, and it is not affected by DST. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible change to logging.handlers.SysLogHandler
On Fri, Apr 6, 2012 at 1:06 PM, Vinay Sajip wrote: > There is a problem with the way logging.handlers.SysLogHandler works > when presented with Unicode messages. According to RFC 5424, Unicode > is supposed to be sent encoded as UTF-8 and preceded by a BOM. > However, the current handler implementation puts the BOM at the start > of the formatted message, and this is wrong in scenarios where you > want to put some additional structured data in front of the > unstructured message part; the BOM is supposed to go after the > structured part (which, therefore, has to be ASCII) and before the > unstructured part. In that scenario, the handler's current behaviour > does not strictly conform to RFC 5424. > > The issue is described in [1]. The BOM was originally added / position > changed in response to [2] and [3]. > > It is not possible to achieve conformance with the current > implementation of the handler, unless you subclass the handler and > override the whole emit() method. This is not ideal. For 3.3, I will > refactor the implementation to expose a method which creates the byte > string which is sent over the wire to the syslog daemon. This method > can then be overridden for specific use cases where needed. > > However, for 2.7 and 3.2, removing the BOM insertion would bring the > implementation into conformance to the RFC, though the entire message > would have to be regarded as just a set of octets. A Unicode message > would still be encoded using UTF-8, but the BOM would be left out. > > I am thinking of removing the BOM insertion in 2.7 and 3.2 - although > it is a change in behaviour, the current behaviour does seem broken > with regard to RFC 5424 conformance. However, as some might disagree > with that assessment and view it as a backwards-incompatible behaviour > change, I thought I should post this to get some opinions about > whether this change is viewed as objectionable. > Given the existing brokenness I personally think that removing the BOM insertion (because it is incorrect) in 2.7 and 3.2 is fine if you cannot find a way to make it correct in 2.7 and 3.2 without breaking existing APIs. could a private method to create the byte string not be added and used in 2.7 and 3.2 that correctly add the BOM? > Regards, > > Vinay Sajip > > [1] http://bugs.python.org/issue14452 > [2] http://bugs.python.org/issue7077 > [3] http://bugs.python.org/issue8795 > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/greg%40krypto.org > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Possible change to logging.handlers.SysLogHandler
Gregory P. Smith krypto.org> writes: > Given the existing brokenness I personally think that removing the BOM > insertion (because it is incorrect) in 2.7 and 3.2 is fine if you cannot find > a way to make it correct in 2.7 and 3.2 without breaking existing APIs. Thanks for the feedback. > could a private method to create the byte string not be added and used in 2.7 > and 3.2 that correctly add the BOM? The problem is that given a format string, the code would not know where to insert the BOM. According to the RFC, it's supposed to go just before the unstructured message part, but that's format-string and hence application-dependent. So some new API will need to be exposed, though I haven't thought through exactly what that will be (for example, it could be a new place-holder for the BOM in the format-string, or some new public methods which are meant to be overridden and so not private). Regards, Vinay Sajip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 418 is too divisive and confusing and should be postponed
On 4/7/2012 5:49 AM, Victor Stinner wrote: 2012/4/7 Janzert: On 4/5/2012 6:32 AM, Victor Stinner wrote: I prefer to use CLOCK_MONOTONIC, not because it is also available for older Linux kernels, but because it is more reliable. Even if the underlying clock source is unstable (unstable frequency), a delta of two reads of the CLOCK_MONOTONIC clock is a result in *seconds*, whereas CLOCK_MONOTONIC_RAW may use an unit a little bit bigger or smaller than a second. time.monotonic() unit is the second, as written in its documentation. I believe the above is only true for sufficiently large time deltas. One of the major purposes of NTP slewing is to give up some short term accuracy in order to achieve long term accuracy (e.g. whenever the clock is found to be ahead of real time it is purposefully ticked slower than real time). I don't think that NTP works like that. NTP only uses very smooth adjustements: ""slewing": change the clock frequency to be slightly faster or slower (which is done with adjtime()). Since the slew rate is limited to 0.5 ms/s, each second of adjustment requires an amortization interval of 2000 s. Thus, an adjustment of many seconds can take hours or days to amortize." http://www.python.org/dev/peps/pep-0418/#ntp-adjustment Right, the description in that paragraph is exactly what I was referring to above. :) It is unfortunate that a clock with a resolution of 1ns may be purposefully thrown off by 500,000ns per second in the short term. In practice you are probably correct that it is better to take the slewed clock even though it may have purposeful short term inaccuracy thrown in than it is to use the completely unadjusted one. So for benchmarking it would not be surprising to be better off with the non-adjusted clock. Ideally there would be a clock that was slewed "just enough" to try and achieve short term accuracy, but I don't know of anything providing that. time.monotonic() is not written for benchmarks. It does not have the highest frequecency, it's primary property is that is monotonic. A side effect is that it is usually the steadiest clock. For example, on Windows time.monotonic() has only an accuracy of 15 ms (15 milliseconds not 15 microseconds). Hmm, I just realized an unfortunate result of that. Since it means time.monotonic() will be too coarse to be useful for frame rate level timing on windows. Janzert ___ Python-Dev mailing list [email protected] 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 glossary
I believe PEP 418 (or at least the discussion) would benefit greatly from a glossary to encourage people to use the same definitions. This is arguably the Definitions section, but it should move either near the end or (preferably) ahead of the Functions. It also needs to be greatly expanded. Here is my strawman proposal, which does use slightly different definitions than the current PEP even for some terms that the PEP does define: Accuracy: Is the answer correct? Any clock will eventually ; if a clock is intended to match , it will need to be back to the "true" time. Adjusted: Resetting a clock to the correct time. This may be done either with a or by . Civil Time: Time of day; external to the system. 10:45:13am is a Civil time; 45 seconds is not. Provided by existing function time.localtime() and time.gmtime(). Not changed by this PEP. Clock: An instrument for measuring time. Different clocks have different characteristics; for example, a clock with may start to after a few minutes, while a less precise clock remained accurate for days. This PEP is primarily concerned with clocks which use a of seconds. Clock_Monotonic: The characteristics expected of a monotonic clock in practice. In addition to being , the should also be and have relatively high , and should be convertible to a of seconds. The tradeoffs often include lack of a defined or mapping to , and being more expensive (in , power usage, or spent within calls to the clock itself) to use. For example, the clock may represent (a constant multiplied by) ticks of a specific quartz timer on a specific CPU core, and calls would therefore require synchronization between cores. The original motivation for this PEP was to provide a cross-platform name for requesting a clock_monotonic clock. Counter: A clock which increments each time a certain event occurs. A counter is , but not . It can be used to generate a unique (and ordered) timestamp, but these timestamps cannot be mapped to ; tick creation may well be bursty, with several advances in the same millisecond followed by several days without any advance. CPU Time: A measure of how much CPU effort has been spent on a certain task. CPU seconds are often normalized (so that a variable number can occur in the same actual second). CPU seconds can be important when profiling, but they do not map directly to user response time, nor are they directly comparable to (real time) seconds. time.clock() is deprecated because it returns seconds on Windows, but CPU seconds on unix, which prevents a consistent cross-platform interpretation. Duration: Elapsed time. The difference between the starting and ending times. A defined creates an implicit (and usually large) duration. More precision can generally be provided for a relatively small . Drift: The accumulated error against "true" time, as defined externally to the system. Epoch: The reference point of a clock. For clocks providing , this is often midnight as the day (and year) rolled over to January 1, 1970. For a clock, the epoch may be undefined (represented as None). Latency: Delay. By the time a clock call returns, the has advanced, possibly by more than the precision of the clock. Microsecond: 1/1,000,000 of a second. Fast enough for most -- but not all -- profiling uses. Millisecond: 1/1,000 of a second. More than adequate for most end-to-end UI measurements, but often too coarse for profiling individual functions. Monotonic: Moving in at most one direction; for clocks, that direction is forward. A (nearly useless) clock that always returns exactly the same time is technically monotonic. In practice, most uses of "monotonic" with respect to clocks actually refer to a stronger set of guarantees, as described under Nanosecond 1/1,000,000,000 of a second. The smallest unit of resolution -- and smaller than the actual precision -- available in current mainstream operating systems. Precision: Significant Digits. What is the smallest duration that the clock can distinguish? This differs from in that a difference greater than the minimum precision is actually meaningful. Process Time: Time elapsed since the process began. It is typically measured in rather than , and typically does not advance while the process is suspended. Real Time: Time in the real world. This differs from in that it is not , but they should otherwise advance in lockstep. It is not related to the "real time" of "Real Time [Operating] Systems". It is sometimes called "wall clock time" to avoid that ambiguity; unfortunately, that introduces different ambiguities. Resolution: Represented Digits. Note that many clocks will have a resolution greater than their actual . Slew: A temporary slight change to a clock's speed, usually intended to correct with respect to an external authority. Stability: Persistence of accuracy. A measure of expecte
