Re: [Python-Dev] PEP 418 glossary
On Wed, 11 Apr 2012 02:49:41 -0400 Jim Jewett jimjjew...@gmail.com wrote: Accuracy: Is the answer correct? Any clock will eventually drift; if a clock is intended to match Civil Time, it will need to be adjusted back to the true time. You may also point to http://en.wikipedia.org/wiki/Accuracy_and_precision We are probably interested in precision more than in accuracy, as far as this PEP is concerned. Regards Antoine. ___ 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] A couple of PEP 418 comments
Hello, I'm just starting a new thread since the old ones are so crowded. First, overall I think the PEP is starting to look really good and insightful! (congratulations to Victor) I have a couple of comments, mostly small ones: function (str): name of the underlying operating system function. I think implementation is a better name here (more precise, and perhaps also more accurate :-)). time.monotonic() time.perf_counter() time.process_time() The descriptions should really stress the scope of the result's validity. My guess (or wish :-)) would be: - time.monotonic(): system-wide results, comparable from one process to another - time.perf_counter(): process-wide results, comparable from one thread to another (?) - time.process_time(): process-wide, by definition It would also be nice to know if some systems may be unable to implement time.monotonic(). GetTickCount() has an precision of 55 ms on Windows 9x. Do we care? :) Precision under recent Windows variants (XP or later) would be more useful. Is there a designated dictator for this PEP? Regards Antoine. ___ 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] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-04-06 - 2012-04-13)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open3377 (+17)
closed 22971 (+36)
total 26348 (+53)
Open issues with patches: 1436
Issues opened (36)
==
#11501: distutils.archive_util should handle absence of zlib module
http://bugs.python.org/issue11501 reopened by eric.araujo
#14310: Socket duplication for windows
http://bugs.python.org/issue14310 reopened by pitrou
#14518: Add bcrypt $2a$ to crypt.py
http://bugs.python.org/issue14518 opened by dholth
#14519: In re's examples the example with scanf() contains wrong analo
http://bugs.python.org/issue14519 opened by py.user
#14521: math.copysign(1., float('nan')) returns -1.
http://bugs.python.org/issue14521 opened by mattip
#14525: ia64-hp-hpux11.31 won't compile Python-2.6.8rc2 without -D_TER
http://bugs.python.org/issue14525 opened by pda
#14527: How to link with an external libffi?
http://bugs.python.org/issue14527 opened by pda
#14529: distutils's build_msi command ignores the data_files argument
http://bugs.python.org/issue14529 opened by Mario.Vilas
#14530: distutils's build_wininst command fails to correctly interpret
http://bugs.python.org/issue14530 opened by Mario.Vilas
#14531: Backtrace should not attempt to open stdin file
http://bugs.python.org/issue14531 opened by ezyang
#14532: multiprocessing module performs a time-dependent hmac comparis
http://bugs.python.org/issue14532 opened by Jon.Oberheide
#14534: Add method to mark unittest.TestCases as do not run.
http://bugs.python.org/issue14534 opened by r.david.murray
#14535: three code examples in docs are not syntax highlighted
http://bugs.python.org/issue14535 opened by ramchandra.apte
#14537: Fatal Python error: Cannot recover from stack overflow. wit
http://bugs.python.org/issue14537 opened by Aaron.Meurer
#14538: HTMLParser: parsing error
http://bugs.python.org/issue14538 opened by Michel.Leunen
#14540: Crash in Modules/_ctypes/libffi/src/dlmalloc.c on ia64-hp-hpux
http://bugs.python.org/issue14540 opened by pda
#14543: Upgrade OpenSSL on Windows to 0.9.8u
http://bugs.python.org/issue14543 opened by dino.viehland
#14544: Limit global keyword name conflicts in language spec to thos
http://bugs.python.org/issue14544 opened by ncoghlan
#14546: lll.py can't handle multiple parameters correctly
http://bugs.python.org/issue14546 opened by carton
#14547: Python symlink to script behaves unexpectedly
http://bugs.python.org/issue14547 opened by j13r
#14548: garbage collection just after multiprocessing's fork causes ex
http://bugs.python.org/issue14548 opened by sbt
#14549: Recursive inclusion of packages
http://bugs.python.org/issue14549 opened by eric.araujo
#14550: os.path.abspath() should have an option to use PWD
http://bugs.python.org/issue14550 opened by csawyer-yumaed
#14554: test module: correction
http://bugs.python.org/issue14554 opened by tshepang
#14555: clock_gettime/settime/getres: Add more clock identifiers
http://bugs.python.org/issue14555 opened by haypo
#14556: telnetlib Telnet.expect fails with timeout=0
http://bugs.python.org/issue14556 opened by Joel.Lovinger
#14558: Documentation for unittest.main does not describe some keyword
http://bugs.python.org/issue14558 opened by jfinkels
#14559: (2.7.3 Regression) PC\8.0 directory can no longer be used to
http://bugs.python.org/issue14559 opened by mitchblank
#14561: python-2.7.2-r3 suffers test failure at test_mhlib
http://bugs.python.org/issue14561 opened by idella5
#14562: urllib2 maybe blocks too long
http://bugs.python.org/issue14562 opened by Anrs.Hu
#14563: Segmentation fault on ctypes.Structure subclass with byte stri
http://bugs.python.org/issue14563 opened by aliles
#14565: is_cgi doesn't function as documented for cgi_directories
http://bugs.python.org/issue14565 opened by v+python
#14566: run_cgi reverts to using unnormalized path
http://bugs.python.org/issue14566 opened by v+python
#14567: http/server.py query string handling incorrect, inefficient
http://bugs.python.org/issue14567 opened by v+python
#14568: HP-UX local libraries not included
http://bugs.python.org/issue14568 opened by adiroiban
#14570: Document json sort_keys parameter properly
http://bugs.python.org/issue14570 opened by ncoghlan
Most recent 15 issues with no replies (15)
==
#14570: Document json sort_keys parameter properly
http://bugs.python.org/issue14570
#14566: run_cgi reverts to using unnormalized path
http://bugs.python.org/issue14566
#14561: python-2.7.2-r3 suffers test failure at test_mhlib
http://bugs.python.org/issue14561
#14558: Documentation for unittest.main does not describe some keyword
http://bugs.python.org/issue14558
#14535: three code examples in docs are not syntax highlighted
http://bugs.python.org/issue14535
Re: [Python-Dev] A couple of PEP 418 comments
The descriptions should really stress the scope of the result's validity. My guess (or wish :-)) would be: - time.monotonic(): system-wide results, comparable from one process to another - time.perf_counter(): process-wide results, comparable from one thread to another (?) - time.process_time(): process-wide, by definition time.monotonic() and time.perf_counter() are process-wide on Windows older than Vista because of GetTickCount() overflow, on other OSes, they are system-wide. It would also be nice to know if some systems may be unable to implement time.monotonic(). You can find such information in the following section: http://www.python.org/dev/peps/pep-0418/#clock-monotonic-clock-monotonic-raw-clock-boottime All OSes provide a monotonic clock, except GNU/Hurd. You mean that it should be mentioned in the time.monotonic() section? GetTickCount() has an precision of 55 ms on Windows 9x. Do we care? :) Precision under recent Windows variants (XP or later) would be more useful. You can get the precision on Windows Seven in the following table: http://www.python.org/dev/peps/pep-0418/#monotonic-clocks I will move the precision of monotonic clock of Windows 9x info into this table. 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] A couple of PEP 418 comments
On Fri, Apr 13, 2012 at 11:29, Victor Stinner I will move the precision of monotonic clock of Windows 9x info into this table. I would just remove it entirely. It's not relevant since it's not supported. ___ 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] Security issue with the tracker
Are there any good small Python libraries for making HTML safe out there? http://goo.gl/D6ag1 Just to make sure that devs are aware of the problem, which was reported more than 6 months ago, gain some traction and release fix sooner. I am not sure what can you do with a stolen bugs.python.org cookie as everything seems audited, but it is a good precedent for a grant on Roundup security research. Have a nice weekend. -- anatoly t. ___ 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] Security issue with the tracker
On Fri, Apr 13, 2012 at 9:23 PM, anatoly techtonik techto...@gmail.com wrote: Are there any good small Python libraries for making HTML safe out there? http://goo.gl/D6ag1 Just to make sure that devs are aware of the problem, which was reported more than 6 months ago, gain some traction and release fix sooner. I am not sure what can you do with a stolen bugs.python.org cookie as everything seems audited, but it is a good precedent for a grant on Roundup security research. Have a nice weekend. Link to security report if you can help http://issues.roundup-tracker.org/issue2550724 -- anatoly t. ___ 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] Security issue with the tracker
bugs.python.org already sanitizes the ok_message and Ezio already posted a patch to the upstream bug tracker, so I don’t see what else we could do. Also note that the Firefox extension NoScript blocks the XSS in this case. Regards ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A couple of PEP 418 comments
On Fri, 13 Apr 2012 18:29:10 +0200 Victor Stinner victor.stin...@gmail.com wrote: The descriptions should really stress the scope of the result's validity. My guess (or wish :-)) would be: - time.monotonic(): system-wide results, comparable from one process to another - time.perf_counter(): process-wide results, comparable from one thread to another (?) - time.process_time(): process-wide, by definition time.monotonic() and time.perf_counter() are process-wide on Windows older than Vista because of GetTickCount() overflow, on other OSes, they are system-wide. Perhaps, but you should say in the PEP, not here ;-) By the way, I wonder if it may be a problem if monotonic() is process-wide under Windows. All OSes provide a monotonic clock, except GNU/Hurd. You mean that it should be mentioned in the time.monotonic() section? Yes, that would be clearer. Regards Antoine. ___ 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 glossary
By the way, I hesitate to add a new mandatory key to
time.get_clock_info() which indicates if the clock includes time
elapsed during a sleep. Is is_realtime a good name for such flag?
Examples:
time.get_clock_info('time')['is_realtime'] == True
time.get_clock_info('monotonic')['is_realtime'] == True
time.get_clock_info('process_time')['is_realtime'] == False
time.get_clock_info('clock')['is_realtime'] == True on Windows, False on Unix
time.get_clock_info('perf_counter')['is_realtime'] == True on Windows
and GNU/Hurd (which will use gettimeofday()), False on Unix. It may
vary depending on which clocks are available.
Another candidate for a new optional key is a flag indicating if the
clock includes time elapsed during system suspend. I don't know how to
call such key. Let's call it include_suspend. Examples:
time.get_clock_info('time')['include_suspend'] == True
time.get_clock_info('monotonic')['include_suspend'] == True on
Windows, False on Mac OS X, Linux and FreeBSD
time.get_clock_info('perf_counter')['include_suspend'] == False on Mac
OS X, Linux and FreeBSD. It is not set on Windows, until someone tells
me how QueryPerformanceCounter() behaves on suspend :-)
time.get_clock_info('process_time')['include_suspend'] == ??? (not set?)
time.get_clock_info('clock')['include_suspend'] == ??? (not set?)
Victor
2012/4/12 R. David Murray rdmur...@bitdance.com:
On Thu, 12 Apr 2012 13:49:43 -,
=?utf-8?B?S3Jpc3Rqw6FuIFZhbHVyIErDs25zc29u?= krist...@ccpgames.com wrote:
Wallclock: This definition is wrong no metter how the BDFL feels about the
word. Please see http://en.wikipedia.org/wiki/Wall_clock_time.
I agree with the BDFL. I have always heard wallclock as referring to
the clock on the wall (that's what the words mean, after all).
When this term became current that meant an *analog* clock that did not
automatically update for daylight savings time, so naturally if you
measure an interval using it it is equivalent to real time.
However, to my mind the implication of the term has always been that
the actual time value returned by a 'wallclock' function can be directly
mapped to the time shown on the clock on the wall (assuming the computer's
clock and the clock on the wall are synchronized, of course).
Heh. Come to think of it, when I first encountered the term it was in
the context of one of the early IBM PCs running DOS, which means that
the computer clock *was* set to the same time as the wall clock.
Thus regardless of what Wikipedia thinks, I think in many people's
minds there is an inherent ambiguity in what the term means. If you
use it to measure an interval, then I think most people would agree
automatically that it is equivalent to real time. But outside of
interval measurement, there is ambiguity.
So I think the definition in the PEP is correct.
--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
[Python-Dev] tracker searches fixed
For those of you who had noticed that since the upgrade the tracker search hasn't been returning a complete set of hits on typical searches, this should now be fixed. --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
[Python-Dev] Questions for the PEP 418: monotonic vs steady, is_adjusted
Hi, Before posting a first draft of the PEP 418 to python-dev, I have some questions. == Naming: time.monotonic() or time.steady()? == I like the steady name but different people complained that the steady name should not be used if the function falls back to the system clock or if the clock is adjusted. time.monotonic() does not fallback to the system clock anymore, it is now always monotonic. There is only one clock used by time.monotonic() which is adjusted: CLOCK_MONOTONIC on Linux. On Linux, CLOCK_MONOTONIC is slewed by NTP, but not stepped. From the user point of view, the clock *is* steady. IMO CLOCK_MONOTONIC_RAW is less steady than CLOCK_MONOTONIC. CLOCK_MONOTONIC_RAW does drift from the real time, whereas NTP adjusts CLOCK_MONOTONIC to make it following closer to the real time. (I mean real time as defined in the Glossary of the PEP, not civil time.) I prefer steady over monotonic because the steady property is what users really expect from a monotonic clock. A monotonic but not steady clock may be useless. All clocks used by the time.monotonic() of the PEP *are* steady. time.monotonic() should be the most steady clock of all available clocks. It may not have the best precision, use time.perf_counter() is you need the highest available precision, but you don't care if the clock is steady or not. == is_adjusted key of time.get_clock_info() == time.get_clock_info() returns a dict with an optional key: is_adjusted. This flag indicates if the clock *can be* adjusted. Should it be called is_adjustable instead? On Windows, the flag value may change at runtime when NTP is enabled or disabled. So the value is the current status of the clock adjustement. The description may be changed to if the clock *is* adjusted. Is a single flag enough? Or would be it better to indicate if the clock: only slewed, slewed *and* stepped, or not adjusted? (3 possible values) I guess that a single flag is enough. If you need more precise information, use the implementation 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] Questions for the PEP 418: monotonic vs steady, is_adjusted
Executive summary: On naming, how about CLOCK_METRONOMIC? Also, is_adjusted is better, until the API is expanded to provide when and how much information about past adjustments. On the glossary, (1) precision, accuracy, and resolution mean different things for points in time and for durations; (2) the definitions of precision and resolution in the glossary still do not agree with Wikipedia. (Wikipedia is wrong is of course an acceptable answer, but if so the fact that authorities differ on the definitions should be mentioned in the glossary.) Proposed definitions: Accuracy: A clock is accurate if it gives the same results as a different accurate clock under the same conditions. Accuracy is measured by the size of the error (compared to physical time). Since error magnitudes will differ, it makes sense to speak of worst-case accuracy and average accuracy (the latter will usually be computed as root mean square error). A clock can be accurate in measuring duration even though it is not accurate in measuring the point in time. [It's hard to see how the opposite could be true.] Precision: A clock is precise if it gives the same results in the same conditions. It's hard to imagine how a computer clock could be imprecise in reporting points of time [perhaps across threads?] but the same duration measured starting at different points in time could easily be different (eg, due to clock slew), and thus imprecise. Precision is measured by the size of the difference (in physical time) between measurements of the same point in, or duration of, time by the clock. Clocks need not be accurate or precise for both points in time and durations; they may be good for one but not the other. Resolution: The resolution of a clock is the shortest duration in physical time that will cause the clock to report a different value. On Sat, Apr 14, 2012 at 9:51 AM, Victor Stinner victor.stin...@gmail.com wrote: == Naming: time.monotonic() or time.steady()? == I like the steady name but different people complained that the steady name should not be used if the function falls back to the system clock or if the clock is adjusted. Unfortunately, both names suck because they mean different things to different people. +1 for the PEP author (you) deciding. FWIW, I would use CLOCK_MONOTONIC on Linux, and the name monotonic. It is not accurate (to physical time in seconds), but it's probably highest precision for *both* points in time and duration. See below for why not steady. It occurs to me that a *metronome* is an example of what we would think of as a steady tick (but not a clock in the sense that the metronome doesn't tell how many ticks). Since clock already implies the counting, how about CLOCK_METRONOMIC to indicate a clock that ticks with a steady beat? (Unfortunately, it's somewhat awkward to pronounce, easily confused with monotonic, and unfamiliar: maybe only musicians will have intuition for it. WDYT?) There is only one clock used by time.monotonic() which is adjusted: CLOCK_MONOTONIC on Linux. On Linux, CLOCK_MONOTONIC is slewed by NTP, but not stepped. From the user point of view, the clock *is* steady. I don't think so (see below). The question is, is it steady *enough*? No clock is perfectly steady, we've already agreed that. It would be nice if time.get_clock_info() reported accuracy (including any inaccuracy due to NTP clock slewing and the like) as well as resolution and precision. That would be optional. By the way, I still think the glossary has precision and resolution defined incorrectly. Several sources on the web define precision to mean degree of repeatability under identical physical conditions. Resolution is defined as the smallest change in physical conditions that produce a change in the measured value. Thus a clock reporting in nanoseconds such that different threads calling clock() simultaneously get a difference of a multiple of 1000 nanoseconds has infinite precision (because if they're actually simultaneous the difference will be zero) but microsecond resolution. The fact that a clock reports values denominated in nanoseconds is mostly irrelevant to the definitions used in measurement terminology, that's an algorithmic consideration. (Of course if the nanosecond values are integral, then picosecond resolution is impossible and picosecond precision is equivalent to infinite precision. But if the values are floats, picosecond precision and resolution both make sense as fractions of a nanosecond.) IMO CLOCK_MONOTONIC_RAW is less steady than CLOCK_MONOTONIC. I disagree. If the drift is consistent (eg, exactly +1 second per day), then the _RAW version is steadier. The point of a steady clock is not that its nominal second approximates a second of real time, it's that the nominal second is always the same length of time. The unit of time of a clock is being slewed differs from its unit of time normally, and this is not steady. CLOCK_MONOTONIC_RAW does drift from
