Issue #26921: Fixed a/an articles.
This commit is contained in:
parent
e54e86b163
commit
cc1c734886
|
@ -146,7 +146,7 @@ Rationale
|
|||
|
||||
Adding augmented assignment will make Python's syntax more complex.
|
||||
Instead of a single assignment operation, there are now twelve
|
||||
assignment operations, eleven of which also perform an binary
|
||||
assignment operations, eleven of which also perform a binary
|
||||
operation. However, these eleven new forms of assignment are easy
|
||||
to understand as the coupling between assignment and the binary
|
||||
operation, and they require no large conceptual leap to
|
||||
|
|
|
@ -242,7 +242,7 @@ Motivation
|
|||
argument to the comparison function is less than the right one, +1
|
||||
indicating the contrapositive, and 0 indicating that the two
|
||||
objects are equal. While this mechanism allows the establishment
|
||||
of a order relationship (e.g. for use by the sort() method of list
|
||||
of an order relationship (e.g. for use by the sort() method of list
|
||||
objects), it has proven to be limited in the context of Numeric
|
||||
Python (NumPy).
|
||||
|
||||
|
|
|
@ -12,7 +12,7 @@ Post-History:
|
|||
Abstract
|
||||
|
||||
This PEP describes the addition of statically nested scoping
|
||||
(lexical scoping) for Python 2.2, and as an source level option
|
||||
(lexical scoping) for Python 2.2, and as a source level option
|
||||
for python 2.1. In addition, Python 2.1 will issue warnings about
|
||||
constructs whose meaning may change when this feature is enabled.
|
||||
|
||||
|
|
|
@ -35,7 +35,7 @@ Rationale
|
|||
the fact that integer division returns the floor of the division.
|
||||
This makes it hard to program correctly, requiring casts to
|
||||
float() in various parts through the code. Python's numerical
|
||||
model stems from C, while an model that might be easier to work with
|
||||
model stems from C, while a model that might be easier to work with
|
||||
can be based on the mathematical understanding of numbers.
|
||||
|
||||
|
||||
|
|
|
@ -377,7 +377,7 @@ Resolved Issues
|
|||
|
||||
- Using the same name for two different operations (getting an
|
||||
iterator from an object and making an iterator for a function
|
||||
with an sentinel value) is somewhat ugly. I haven't seen a
|
||||
with a sentinel value) is somewhat ugly. I haven't seen a
|
||||
better name for the second operation though, and since they both
|
||||
return an iterator, it's easy to remember.
|
||||
|
||||
|
|
|
@ -68,7 +68,7 @@ Proposed Solutions
|
|||
|
||||
1. Adding an optimization to the Python compiler and VM
|
||||
which detects the above if-elif-else construct and
|
||||
generates special opcodes for it which use an read-only
|
||||
generates special opcodes for it which use a read-only
|
||||
dictionary for storing jump offsets.
|
||||
|
||||
2. Adding new syntax to Python which mimics the C style
|
||||
|
|
|
@ -66,7 +66,7 @@ utility of other itertools will be enhanced by generator expressions::
|
|||
dotproduct = sum(x*y for x,y in itertools.izip(x_vector, y_vector))
|
||||
|
||||
Having a syntax similar to list comprehensions also makes it easy to
|
||||
convert existing code into an generator expression when scaling up
|
||||
convert existing code into a generator expression when scaling up
|
||||
application.
|
||||
|
||||
Early timings showed that generators had a significant performance
|
||||
|
|
|
@ -349,7 +349,7 @@ Proposed Implementation
|
|||
unlocked during a synchronized block.
|
||||
|
||||
During an unqualified synchronized block (the use of the
|
||||
`synchronize' keyword without an target argument) a lock could be
|
||||
`synchronize' keyword without a target argument) a lock could be
|
||||
created and associated with the synchronized code block object.
|
||||
Any threads that are to execute the block must first acquire the
|
||||
code block lock.
|
||||
|
|
|
@ -123,10 +123,10 @@ Static Constraints on Bytecode Instruction Operands
|
|||
boundaries and must fall on an instruction, never between an
|
||||
instruction and its operands.
|
||||
|
||||
2. The operand of a LOAD_* instruction must be an valid index into
|
||||
2. The operand of a LOAD_* instruction must be a valid index into
|
||||
its corresponding data structure.
|
||||
|
||||
3. The operand of a STORE_* instruction must be an valid index
|
||||
3. The operand of a STORE_* instruction must be a valid index
|
||||
into its corresponding data structure.
|
||||
|
||||
|
||||
|
@ -149,7 +149,7 @@ Structural Constraints between Bytecode Instructions
|
|||
|
||||
Implementation
|
||||
|
||||
This PEP is the working document for an Python bytecode
|
||||
This PEP is the working document for a Python bytecode
|
||||
verification implementation written in Python. This
|
||||
implementation is not used implicitly by the PVM before executing
|
||||
any bytecode, but is to be used explicitly by users concerned
|
||||
|
|
|
@ -166,7 +166,7 @@ New C API functions
|
|||
``PyObject* PyImport_NotifyLoadedByModule(PyObject *module)``
|
||||
Notify the post import system that a module was requested. Returns the
|
||||
a borrowed reference to the same module object or NULL if an error has
|
||||
occured. The function calls only the hooks for the module itself an not
|
||||
occured. The function calls only the hooks for the module itself and not
|
||||
its parents. The function must be called with the import lock acquired.
|
||||
|
||||
``PyObject* PyImport_NotifyLoadedByName(const char *name)``
|
||||
|
|
|
@ -174,7 +174,7 @@ output. The feature is intended for scripting, e.g.
|
|||
``distutils.sysconfig`` will get methods to access the private variables
|
||||
of site. (not yet implemented)
|
||||
|
||||
The Windows updater needs to be updated, too. It should create an menu
|
||||
The Windows updater needs to be updated, too. It should create a menu
|
||||
item which opens the user site directory in a new explorer windows.
|
||||
|
||||
|
||||
|
|
|
@ -149,7 +149,7 @@ Performance Comparison
|
|||
picking the best run of that 100 iterations via the timeit module.
|
||||
|
||||
First, to identify the overhead of the spawning of the workers, we
|
||||
execute an function which is simply a pass statement (empty):
|
||||
execute a function which is simply a pass statement (empty):
|
||||
|
||||
cmd: python run_benchmarks.py empty_func.py
|
||||
Importing empty_func
|
||||
|
|
|
@ -176,7 +176,7 @@ Does OrderedDict support indexing, slicing, and whatnot?
|
|||
the order of key insertion. The only sequence-like addition is
|
||||
support for ``reversed``.
|
||||
|
||||
An further advantage of not allowing indexing is that it leaves open
|
||||
A further advantage of not allowing indexing is that it leaves open
|
||||
the possibility of a fast C implementation using linked lists.
|
||||
|
||||
Does OrderedDict support alternate sort orders such as alphabetical?
|
||||
|
@ -235,7 +235,7 @@ How does OrderedDict handle equality testing?
|
|||
insensitive comparison is used. This allows ordered dictionaries
|
||||
to be substituted anywhere regular dictionaries are used.
|
||||
|
||||
How __repr__ format will maintain order during an repr/eval round-trip?
|
||||
How __repr__ format will maintain order during a repr/eval round-trip?
|
||||
|
||||
OrderedDict([('a', 1), ('b', 2)])
|
||||
|
||||
|
|
|
@ -269,7 +269,7 @@ INSTALLER
|
|||
---------
|
||||
|
||||
The `install` command has a new option called `installer`. This option
|
||||
is the name of the tool used to invoke the installation. It's an normalized
|
||||
is the name of the tool used to invoke the installation. It's a normalized
|
||||
lower-case string matching `[a-z0-9_\-\.]`.
|
||||
|
||||
$ python setup.py install --installer=pkg-system
|
||||
|
|
|
@ -144,7 +144,7 @@ method:
|
|||
finder.find_package_portion(fullname)
|
||||
|
||||
This method will be called in the same manner as find_module, and it
|
||||
must return an string to be added to the package's ``__path__``.
|
||||
must return a string to be added to the package's ``__path__``.
|
||||
If the finder doesn't find a portion of the package, it shall return
|
||||
``None``. Raising ``AttributeError`` from above call will be treated
|
||||
as non-conformance with this PEP, and the exception will be ignored.
|
||||
|
|
|
@ -160,7 +160,7 @@ PyUnicode_New::
|
|||
|
||||
Both parameters must denote the eventual size/range of the strings.
|
||||
In particular, codecs using this API must compute both the number of
|
||||
characters and the maximum character in advance. An string is
|
||||
characters and the maximum character in advance. A string is
|
||||
allocated according to the specified size and character range and is
|
||||
null-terminated; the actual characters in it may be uninitialized.
|
||||
|
||||
|
|
|
@ -90,7 +90,7 @@ StreamReader and StreamWriter issues
|
|||
(e.g. UTF-16).
|
||||
* Each codec has to reimplement its own StreamReader and StreamWriter
|
||||
class, even if it's trivial (just call the encoder/decoder).
|
||||
* codecs.open(filename, "r") creates a io.TextIOWrapper object.
|
||||
* codecs.open(filename, "r") creates an io.TextIOWrapper object.
|
||||
* No codec implements an optimized method in StreamReader or
|
||||
StreamWriter based on the specificities of the codec.
|
||||
|
||||
|
|
|
@ -391,7 +391,7 @@ Alternatives: API design
|
|||
Add a string argument to specify the return type
|
||||
------------------------------------------------
|
||||
|
||||
Add an string argument to function returning timestamps, example:
|
||||
Add a string argument to function returning timestamps, example:
|
||||
time.time(format="datetime"). A string is more extensible than a type: it is
|
||||
possible to request a format that has no type, like a tuple of integers.
|
||||
|
||||
|
@ -477,7 +477,7 @@ Add a boolean argument
|
|||
Because we only need one new type (Decimal), a simple boolean flag can be
|
||||
added. Example: time.time(decimal=True) or time.time(hires=True).
|
||||
|
||||
Such flag would require to do an hidden import which is considered as a bad
|
||||
Such flag would require to do a hidden import which is considered as a bad
|
||||
practice.
|
||||
|
||||
The boolean argument API was rejected because it is not "pythonic". Changing
|
||||
|
|
|
@ -709,7 +709,7 @@ Hardware clocks
|
|||
List of hardware clocks
|
||||
-----------------------
|
||||
|
||||
* HPET: An High Precision Event Timer (HPET) chip consists of a 64-bit
|
||||
* HPET: A High Precision Event Timer (HPET) chip consists of a 64-bit
|
||||
up-counter (main counter) counting at least at 10 MHz and a set of
|
||||
up to 256 comparators (at least 3). Each HPET can have up to 32
|
||||
timers. HPET can cause around 3 seconds of drift per day.
|
||||
|
@ -1502,7 +1502,7 @@ notifications
|
|||
Footnotes
|
||||
=========
|
||||
|
||||
.. [#pseudo] "_time" is an hypothetical module only used for the example.
|
||||
.. [#pseudo] "_time" is a hypothetical module only used for the example.
|
||||
The time module is implemented in C and so there is no need for
|
||||
such a module.
|
||||
|
||||
|
|
|
@ -41,7 +41,7 @@ the *bInheritHandles* parameter set to ``TRUE`` (when
|
|||
``subprocess.Popen`` is created with ``close_fds=False`` for example).
|
||||
Windows does not have "close-on-exec" flag but an inheritance flag which
|
||||
is just the opposite value. For example, setting close-on-exec flag
|
||||
means clearing the ``HANDLE_FLAG_INHERIT`` flag of an handle.
|
||||
means clearing the ``HANDLE_FLAG_INHERIT`` flag of a handle.
|
||||
|
||||
|
||||
Status in Python 3.3
|
||||
|
@ -263,7 +263,7 @@ default is also the default on POSIX and on Windows. This alternative is
|
|||
the most convervative option.
|
||||
|
||||
This option does not solve issues listed in the `Rationale`_
|
||||
section, it only provides an helper to fix them. All functions creating
|
||||
section, it only provides a helper to fix them. All functions creating
|
||||
file descriptors have to be modified to set *cloexec=True* in each
|
||||
module used by an application to fix all these issues.
|
||||
|
||||
|
|
|
@ -65,10 +65,10 @@ proposes to make the status disagreement irrelevant by explicitly
|
|||
allowing more liberal backporting than for other stdlib modules.
|
||||
|
||||
Python does have many advanced features yet Python is well known for
|
||||
being a easy computer language for beginners [3]_. A major Python
|
||||
being an easy computer language for beginners [3]_. A major Python
|
||||
philosophy is "batteries included" which is best demonstrated in
|
||||
Python's standard library with many modules that are not typically
|
||||
included with other programming languages [4]_. IDLE is a important
|
||||
included with other programming languages [4]_. IDLE is an important
|
||||
"battery" in the Python toolbox because it allows a beginner to get
|
||||
started quickly without downloading and configuring a third party IDE.
|
||||
IDLE represents a commitment by the Python community to encouage the
|
||||
|
|
|
@ -388,7 +388,7 @@ Pybench
|
|||
|
||||
The pybench output below compares an implementation of this PEP with the
|
||||
regular source tree, both based on changeset a5681f50bae2, run on an idle
|
||||
machine an Core i7 processor running Centos 6.4.
|
||||
machine and Core i7 processor running Centos 6.4.
|
||||
|
||||
Even though the machine was idle there were clear differences between runs,
|
||||
I've seen difference in "minimum time" vary from -0.1% to +1.5%, with similar
|
||||
|
|
|
@ -77,7 +77,7 @@ The idea of tracing memory allocations is not new. It was first
|
|||
implemented in the PySizer project in 2005. PySizer was implemented
|
||||
differently: the traceback was stored in frame objects and some Python
|
||||
types were linked the trace with the name of object type. PySizer patch
|
||||
on CPython adds a overhead on performances and memory footprint, even if
|
||||
on CPython adds an overhead on performances and memory footprint, even if
|
||||
the PySizer was not used. tracemalloc attachs a traceback to the
|
||||
underlying layer, to memory blocks, and has no overhead when the module
|
||||
is not tracing memory allocations.
|
||||
|
|
|
@ -25,7 +25,7 @@ Rejection
|
|||
|
||||
See the rationale at
|
||||
https://mail.python.org/pipermail/python-dev/2015-May/140003.html
|
||||
and for a earlier partial review, see
|
||||
and for an earlier partial review, see
|
||||
https://mail.python.org/pipermail/python-dev/2013-October/129937.html .
|
||||
|
||||
Rationale
|
||||
|
|
|
@ -240,7 +240,7 @@ combined repo hosting and code review management platform, but doesn't
|
|||
directly integrate the two by offering online merges. This creates the
|
||||
opportunity to blend the low barrier to entry benefits of the GitHub/BitBucket
|
||||
pull request model with the mentoring and task hand-off benefits of Gerrit
|
||||
in defining a online code merging model for Kallithea in collaboration with
|
||||
in defining an online code merging model for Kallithea in collaboration with
|
||||
the upstream Kallithea developers.
|
||||
|
||||
|
||||
|
|
|
@ -27,7 +27,7 @@ Floating point values contain limited precision, which results in
|
|||
their being unable to exactly represent some values, and for errors to
|
||||
accumulate with repeated computation. As a result, it is common
|
||||
advice to only use an equality comparison in very specific situations.
|
||||
Often a inequality comparison fits the bill, but there are times
|
||||
Often an inequality comparison fits the bill, but there are times
|
||||
(often in testing) where the programmer wants to determine whether a
|
||||
computed value is "close" to an expected value, without requiring them
|
||||
to be exactly equal. This is common enough, particularly in testing,
|
||||
|
@ -88,7 +88,7 @@ to set a tolerance of 5%, pass tol=0.05. The default tolerance is 1e-9,
|
|||
which assures that the two values are the same within about 9 decimal
|
||||
digits. ``rel_tol`` must be greater than 0.0
|
||||
|
||||
``abs_tol``: is an minimum absolute tolerance level -- useful for
|
||||
``abs_tol``: is a minimum absolute tolerance level -- useful for
|
||||
comparisons near zero.
|
||||
|
||||
Modulo error checking, etc, the function will return the result of::
|
||||
|
|
|
@ -201,7 +201,7 @@ folding by ensuring the parsed template is always constant, even when the
|
|||
field values and format specifiers include variable substitution expressions.
|
||||
|
||||
The raw template is just the interpolation template as a string. By default,
|
||||
it is used to provide an human readable representation for the interpolation
|
||||
it is used to provide a human readable representation for the interpolation
|
||||
template.
|
||||
|
||||
The parsed template consists of a tuple of 2-tuples, with each 2-tuple
|
||||
|
|
|
@ -253,7 +253,7 @@ Comparison To Other Languages
|
|||
def openssl_random_pseudo_bytes(length:int)->Tuple[str, bool]
|
||||
|
||||
This function returns a pseudo-random string of bytes of the given
|
||||
length, and an boolean flag giving whether the string is considered
|
||||
length, and a boolean flag giving whether the string is considered
|
||||
cryptographically strong. The PHP manual suggests that returning
|
||||
anything but True should be rare except for old or broken platforms.
|
||||
|
||||
|
|
|
@ -65,7 +65,7 @@ Guard example
|
|||
=============
|
||||
|
||||
Pseudo-code of a fast guard to check if a dictionary entry was modified
|
||||
(created, updated or deleted) using an hypothetical
|
||||
(created, updated or deleted) using a hypothetical
|
||||
``dict_get_version(dict)`` function::
|
||||
|
||||
UNSET = object()
|
||||
|
@ -227,7 +227,7 @@ support weak references.
|
|||
The version increase must be atomic. In CPython, the Global Interpreter
|
||||
Lock (GIL) already protects ``dict`` methods to make changes atomic.
|
||||
|
||||
Example using an hypothetical ``dict_get_version(dict)`` function::
|
||||
Example using a hypothetical ``dict_get_version(dict)`` function::
|
||||
|
||||
>>> d = {}
|
||||
>>> dict_get_version(d)
|
||||
|
|
|
@ -114,7 +114,7 @@ just to explain the principle.
|
|||
Hypothetical myoptimizer module
|
||||
-------------------------------
|
||||
|
||||
Examples in this PEP uses an hypothetical ``myoptimizer`` module which
|
||||
Examples in this PEP uses a hypothetical ``myoptimizer`` module which
|
||||
provides the following functions and types:
|
||||
|
||||
* ``specialize(func, code, guards)``: add the specialized code `code`
|
||||
|
|
|
@ -357,7 +357,7 @@ Rationale
|
|||
=========
|
||||
|
||||
This PEP started with a long mailing list thread on distutils-sig [#thread]_.
|
||||
Subsequent to that a online meeting was held to debug all the positions folk
|
||||
Subsequent to that an online meeting was held to debug all the positions folk
|
||||
had. Minutes from that were posted to the list [#minutes]_.
|
||||
|
||||
This specification is a translation of the consensus reached there into PEP
|
||||
|
|
|
@ -146,7 +146,7 @@ isNegInf(value)
|
|||
Determine if the argument is a IEEE 754 negative infinity value.
|
||||
|
||||
isFinite(value)
|
||||
Determine if the argument is an finite IEEE 754 value (i.e., is
|
||||
Determine if the argument is a finite IEEE 754 value (i.e., is
|
||||
not NaN, positive, or negative infinity).
|
||||
|
||||
isInf(value)
|
||||
|
|
|
@ -208,7 +208,7 @@ B. Should the default behaviour accept only ASCII identifiers, or
|
|||
subtly/unknowingly wrong; rarely wrong is worse than obviously wrong.
|
||||
|
||||
2. Better to raise a warning than to fail silently when encountering
|
||||
an probably unexpected situation.
|
||||
a probably unexpected situation.
|
||||
|
||||
3. All of current usage is ASCII-only; the vast majority of future
|
||||
usage will be ASCII-only.
|
||||
|
|
|
@ -306,7 +306,7 @@ with the abstract base classes proposed in PEP 3119. After further
|
|||
discussion and deliberation, a compromise and a delegation of
|
||||
responsibilities and use-cases has been worked out as follows:
|
||||
|
||||
* Roles provide a way of indicating a object's semantics and abstract
|
||||
* Roles provide a way of indicating an object's semantics and abstract
|
||||
capabilities. A role may define abstract methods, but only as a
|
||||
way of delineating an interface through which a particular set of
|
||||
semantics are accessed. An ``Ordering`` role might require that
|
||||
|
|
|
@ -359,7 +359,7 @@ Proposal D - Explicit iterators
|
|||
|
||||
Rather than embellishing for and while loop syntax with labels, the
|
||||
programmer wishing to use labeled breaks would be required to create
|
||||
the iterator explicitly and assign it to a identifier if he or she
|
||||
the iterator explicitly and assign it to an identifier if he or she
|
||||
wanted to ``break`` out of or ``continue`` that loop from within a
|
||||
deeper loop.
|
||||
|
||||
|
|
|
@ -1032,7 +1032,7 @@ Contingency Plans
|
|||
|
||||
There is a chance that we will not be able to reduce memory usage or startup
|
||||
time to a level satisfactory to the CPython community. Our primary contingency
|
||||
plan for this situation is to shift from a online just-in-time compilation
|
||||
plan for this situation is to shift from an online just-in-time compilation
|
||||
strategy to an offline ahead-of-time strategy using an instrumented CPython
|
||||
interpreter loop to obtain feedback. This is the same model used by gcc's
|
||||
feedback-directed optimizations (`-fprofile-generate`) [#gcc-fdo]_ and
|
||||
|
|
|
@ -16,7 +16,7 @@ Abstract
|
|||
This PEP describes an abstraction of asynchronous IO for the Python
|
||||
standard library.
|
||||
|
||||
The goal is to reach a abstraction that can be implemented by many
|
||||
The goal is to reach an abstraction that can be implemented by many
|
||||
different asynchronous IO backends and provides a target for library
|
||||
developers to write code portable between those different backends.
|
||||
|
||||
|
|
|
@ -172,11 +172,11 @@ to Alexandre Vassalotti's work):
|
|||
* ``SHORT_BINUNICODE``: push a utf8-encoded str object with a one-byte
|
||||
size prefix (therefore less than 256 bytes long).
|
||||
|
||||
* ``BINUNICODE8``: push a utf8-encoded str object with a eight-byte
|
||||
* ``BINUNICODE8``: push a utf8-encoded str object with an eight-byte
|
||||
size prefix (for strings longer than 2**32 bytes, which therefore cannot
|
||||
be serialized using ``BINUNICODE``).
|
||||
|
||||
* ``BINBYTES8``: push a bytes object with a eight-byte size prefix
|
||||
* ``BINBYTES8``: push a bytes object with an eight-byte size prefix
|
||||
(for bytes objects longer than 2**32 bytes, which therefore cannot be
|
||||
serialized using ``BINBYTES``).
|
||||
|
||||
|
|
Loading…
Reference in New Issue