[Python-checkins] peps: PEP 418: Stephen J. Turnbull's patch 2: english
victor.stinner
python-checkins at python.org
Sat Apr 21 21:18:08 CEST 2012
http://hg.python.org/peps/rev/36943ff6a058
changeset: 4292:36943ff6a058
user: Victor Stinner <victor.stinner at gmail.com>
date: Sat Apr 21 21:18:13 2012 +0200
summary:
PEP 418: Stephen J. Turnbull's patch 2: english
files:
pep-0418.txt | 22 ++++++++++++----------
1 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/pep-0418.txt b/pep-0418.txt
--- a/pep-0418.txt
+++ b/pep-0418.txt
@@ -22,8 +22,8 @@
=========
If a program uses the system time to schedule events or to implement
-a timeout, it will not run events at the right moment or stop the
-timeout too early or too late when the system time is set manually or
+a timeout, it may fail to run events at the right moment or stop the
+timeout too early or too late when the system time is changed manually or
adjusted automatically by NTP. A monotonic clock should be used
instead to not be affected by system time updates:
``time.monotonic()``.
@@ -36,13 +36,14 @@
used instead to always get the most precise performance counter with a
portable behaviour (ex: include time spend during sleep).
-To measure CPU time, Python does not provide directly a portable
-function. ``time.clock()`` can be used on Unix, but it has a bad
+Until now, Python did not provide directly a portable
+function to measure CPU time. ``time.clock()`` can be used on Unix,
+but it has bad
precision. ``resource.getrusage()`` or ``os.times()`` can also be
used on Unix, but they require to compute the sum of time
spent in kernel space and user space. The new ``time.process_time()``
function acts as a portable counter that always measures CPU time
-(doesn't include time elapsed during sleep) and has the best available
+(excluding time elapsed during sleep) and has the best available
precision.
Each operating system implements clocks and performance counters
@@ -141,8 +142,9 @@
On Windows versions older than Vista, ``time.monotonic()`` detects
``GetTickCount()`` integer overflow (32 bits, roll-over after 49.7
-days): it increases a delta by 2\ :sup:`32` each time that an overflow
-is detected. The delta is stored in the process-local state and so
+days). It increases an internal epoch (reference time by) 2\
+:sup:`32` each time that an overflow is detected. The epoch is stored
+in the process-local state and so
the value of ``time.monotonic()`` may be different in two Python
processes running for more than 49 days. On more recent versions of
Windows and on other operating systems, ``time.monotonic()`` is
@@ -563,7 +565,7 @@
Working around operating system bugs?
-------------------------------------
-Should Python ensure manually that a monotonic clock is truly
+Should Python ensure that a monotonic clock is truly
monotonic by computing the maximum with the clock value and the
previous value?
@@ -578,7 +580,7 @@
`KB274323`_ contains a code example to workaround the bug (use
GetTickCount() to detect QueryPerformanceCounter() leap).
-Issues of a hacked monotonic function:
+Issues with "correcting" non-monotonicities:
* if the clock is accidentally set forward by an hour and then back
again, you wouldn't have a useful clock for an hour
@@ -946,7 +948,7 @@
^^^^^^^^^^^^^^^^^^
Mac OS X provides a monotonic clock: mach_absolute_time(). It is
-based on absolute elapsed time delta since system boot. It is not
+based on absolute elapsed time since system boot. It is not
adjusted and cannot be set.
mach_timebase_info() gives a fraction to convert the clock value to a
--
Repository URL: http://hg.python.org/peps
More information about the Python-checkins
mailing list