merge
This commit is contained in:
commit
0bc2589589
16
pep-0008.txt
16
pep-0008.txt
|
@ -841,16 +841,20 @@ Programming Recommendations
|
|||
whenever they do something other than acquire and release resources.
|
||||
For example:
|
||||
|
||||
Yes: with conn.begin_transaction():
|
||||
Yes::
|
||||
|
||||
with conn.begin_transaction():
|
||||
do_stuff_in_transaction(conn)
|
||||
|
||||
No: with conn:
|
||||
No::
|
||||
|
||||
with conn:
|
||||
do_stuff_in_transaction(conn)
|
||||
|
||||
The latter example doesn't provide any information to indicate that
|
||||
the __enter__ and __exit__ methods are doing something other than
|
||||
closing the connection after a transaction. Being explicit is
|
||||
important in this case.
|
||||
The latter example doesn't provide any information to indicate that
|
||||
the __enter__ and __exit__ methods are doing something other than
|
||||
closing the connection after a transaction. Being explicit is
|
||||
important in this case.
|
||||
|
||||
- Use string methods instead of the string module.
|
||||
|
||||
|
|
46
pep-0418.txt
46
pep-0418.txt
|
@ -114,20 +114,15 @@ Get information on the specified clock. Supported clock names:
|
|||
* ``"process_time"``: ``time.process_time()``
|
||||
* ``"time"``: ``time.time()``
|
||||
|
||||
Return a dictionary with the following keys:
|
||||
Return a ``time.clock_info`` object which has the following attributes:
|
||||
|
||||
* Mandatory keys:
|
||||
|
||||
* ``"implementation"`` (str): name of the underlying operating system
|
||||
function. Examples: ``"QueryPerformanceCounter()"``,
|
||||
``"clock_gettime(CLOCK_REALTIME)"``.
|
||||
* ``"resolution"`` (float): resolution in seconds of the clock.
|
||||
* ``"is_monotonic"`` (bool): True if the clock cannot go backward.
|
||||
|
||||
* Optional keys:
|
||||
|
||||
* ``"is_adjusted"`` (bool): True if the clock is adjusted (e.g. by a
|
||||
NTP daemon).
|
||||
* ``implementation`` (str): name of the underlying operating system
|
||||
function. Examples: ``"QueryPerformanceCounter()"``,
|
||||
``"clock_gettime(CLOCK_REALTIME)"``.
|
||||
* ``is_monotonic`` (bool): True if the clock cannot go backward.
|
||||
* ``is_adjusted`` (bool): True if the clock is adjusted (e.g. by a
|
||||
NTP daemon).
|
||||
* ``resolution`` (float): resolution in seconds of the clock.
|
||||
|
||||
|
||||
time.monotonic()
|
||||
|
@ -610,14 +605,14 @@ Glossary
|
|||
|
||||
:Clock:
|
||||
An instrument for measuring time. Different clocks have different
|
||||
characteristics; for example, a clock with <nanosecond>
|
||||
characteristics; for example, a clock with nanosecond
|
||||
<precision> may start to <drift> after a few minutes, while a less
|
||||
precise clock remained accurate for days. This PEP is primarily
|
||||
concerned with clocks which use a unit of seconds.
|
||||
|
||||
:Counter:
|
||||
A clock which increments each time a certain event occurs. A
|
||||
counter is <strictly monotonic>, but not <clock_monotonic>. It can
|
||||
counter is strictly monotonic, but not a monotonic clock. It can
|
||||
be used to generate a unique (and ordered) timestamp, but these
|
||||
timestamps cannot be mapped to <civil time>; tick creation may well
|
||||
be bursty, with several advances in the same millisecond followed
|
||||
|
@ -630,12 +625,6 @@ Glossary
|
|||
when profiling, but they do not map directly to user response time,
|
||||
nor are they directly comparable to (real time) seconds.
|
||||
|
||||
:Duration:
|
||||
Elapsed time. The difference between the starting and ending
|
||||
times. A defined <epoch> creates an implicit (and usually large)
|
||||
duration. More precision can generally be provided for a
|
||||
relatively small <duration>.
|
||||
|
||||
:Drift:
|
||||
The accumulated error against "true" time, as defined externally to
|
||||
the system. Drift may be due to imprecision, or to a difference
|
||||
|
@ -657,12 +646,7 @@ Glossary
|
|||
Moving in at most one direction; for clocks, that direction is
|
||||
forward. The <clock> should also be <steady>, and should be
|
||||
convertible to a unit of seconds. The tradeoffs often include lack
|
||||
of a defined <epoch> or mapping to <Civil Time>, and being more
|
||||
expensive (in <latency>, power usage, or <duration> 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.
|
||||
of a defined <epoch> or mapping to <Civil Time>.
|
||||
|
||||
:Precision:
|
||||
The amount of deviation among measurements of the same physical
|
||||
|
@ -968,11 +952,9 @@ Mac OS X provides a monotonic clock: mach_absolute_time(). It is
|
|||
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
|
||||
number of nanoseconds. According to the documentation (`Technical Q&A
|
||||
QA1398 <https://developer.apple.com/library/mac/#qa/qa1398/>`_),
|
||||
mach_timebase_info() is always equal to one and never fails, even if
|
||||
the function may fail according to its prototype.
|
||||
mach_timebase_info() gives a fraction to convert the clock value to a number of
|
||||
nanoseconds. See also the `Technical Q&A QA1398
|
||||
<https://developer.apple.com/library/mac/#qa/qa1398/>`_.
|
||||
|
||||
mach_absolute_time() stops during a sleep on a PowerPC CPU, but not on
|
||||
an Intel CPU: `Different behaviour of mach_absolute_time() on i386/ppc
|
||||
|
|
|
@ -122,8 +122,8 @@ for a module or package named "foo":
|
|||
* If not, but ``foo`` is found and is a directory, it is recorded.
|
||||
|
||||
If the scan along the parent path completes without finding a module
|
||||
or package, then a namespace package is created. The new namespace
|
||||
package:
|
||||
or package and at least one directory was recorded, then a namespace
|
||||
package is created. The new namespace package:
|
||||
|
||||
* Has a ``__file__`` attribute set to the first directory that was
|
||||
found during the scan, including the trailing path separator.
|
||||
|
|
Loading…
Reference in New Issue