Re: [Python-Dev] PEP 418 glossary
On Wed, 11 Apr 2012 02:49:41 -0400 Jim Jewett wrote: > > 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. 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 [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] 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 [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] 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 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/issue14
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 [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] 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 [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] 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 [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] Security issue with the tracker
On Fri, Apr 13, 2012 at 9:23 PM, anatoly techtonik 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 [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] 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 [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] A couple of PEP 418 comments
On Fri, 13 Apr 2012 18:29:10 +0200 Victor Stinner 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 [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 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 :
> On Thu, 12 Apr 2012 13:49:43 -,
> =?utf-8?B?S3Jpc3Rqw6FuIFZhbHVyIErDs25zc29u?= 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
[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] 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 [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] 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 [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] 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
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_MONOTO
Re: [Python-Dev] Questions for the PEP 418: monotonic vs steady, is_adjusted
On Sat, Apr 14, 2012 at 02:51, Victor Stinner wrote: > Hi, > > Before posting a first draft of the PEP 418 to python-dev, I have some > questions. > > == Naming: time.monotonic() or time.steady()? == The clock is monotonic by all reasonable definitions of monotonic (ie they don't go backwards). There are some reasonable definitions of steady in which the clocks returned aren't steady (ie, the rate is not necessarily the same always), especially when it comes to system suspends, but also with regards to slew adjustments. Hence the function should be called monotonic(). //Lennart ___ 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
