Fix case of "Python" in PEP 637 (#1794)

This commit is contained in:
Barry Warsaw 2021-02-03 19:22:25 -08:00 committed by GitHub
parent 3b0098ad9a
commit d3f48ed58f
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 8 additions and 8 deletions

View File

@ -159,7 +159,7 @@ specification would improve notation and provide additional value:
exactly this notation in its "Unpacking: Star Operator" section.
It is important to note that how the notation is interpreted is up to the
implementation. This PEP only defines and dictates the behavior of python
implementation. This PEP only defines and dictates the behavior of Python
regarding passed keyword arguments, not how these arguments should be
interpreted and used by the implementing class.
@ -172,7 +172,7 @@ and how it is different from a function call.
Subscripting ``obj[x]`` is, effectively, an alternate and specialised form of
function call syntax with a number of differences and restrictions compared to
``obj(x)``. The current python syntax focuses exclusively on position to express
``obj(x)``. The current Python syntax focuses exclusively on position to express
the index, and also contains syntactic sugar to refer to non-punctiform
selection (slices). Some common examples::
@ -197,7 +197,7 @@ violate this intrinsic meaning.
The second difference of the indexing notation compared to a function
is that indexing can be used for both getting and setting operations.
In python, a function cannot be on the left hand side of an assignment. In
In Python, a function cannot be on the left hand side of an assignment. In
other words, both of these are valid::
>>> x = a[1, 2]
@ -526,7 +526,7 @@ With the introduction of the new notation, a few corner cases need to be analyse
# Given type(obj).__setitem__(obj, index, value):
obj[1, value=3] = 5
This poses no issue because the value is passed automatically, and the python interpreter will raise
This poses no issue because the value is passed automatically, and the Python interpreter will raise
``TypeError: got multiple values for keyword argument 'value'``
@ -621,7 +621,7 @@ Resolution of the indexing operation is performed through a call to the followin
- ``PyObject_SetItem(PyObject *o, PyObject *key, PyObject *value)`` for the set operation
- ``PyObject_DelItem(PyObject *o, PyObject *key)`` for the del operation
These functions are used extensively within the python executable, and are
These functions are used extensively within the Python executable, and are
also part of the public C API, as exported by ``Include/abstract.h``. It is clear that
the signature of this function cannot be changed, and different C level functions
need to be implemented to support the extended call. We propose
@ -791,7 +791,7 @@ The problems with this approach were found to be:
- the solution relies on the assumption that all keyword indices necessarily map
into positional indices, or that they must have a name. This assumption may be
false: xarray, which is the primary python package for numpy arrays with
false: xarray, which is the primary Python package for numpy arrays with
labelled dimensions, supports indexing by additional dimensions (so called
"non-dimension coordinates") that don't correspond directly to the dimensions
of the underlying numpy array, and those have no position to match up to.
@ -911,7 +911,7 @@ non-default arguments after defaulted one::
def __setitem__(self, index=SENTINEL, value=NEVERUSED, *, k)
which seems ugly, redundant and confusing. We must therefore accept that some
form of sentinel index must be passed by the python implementation when the
form of sentinel index must be passed by the Python implementation when the
``obj[k=3]`` notation is used. This also means that default arguments to those
parameters are simply never going to be used (but it's already the
case with the current implementation, so no change there).
@ -1040,7 +1040,7 @@ Common objections
function calls are out of the question. Moreover, function calls do not handle
slice notation, which is commonly used in some cases for arrays.
One problem is type hint creation has been extended to built-ins in python 3.9,
One problem is type hint creation has been extended to built-ins in Python 3.9,
so that you do not have to import Dict, List, et al anymore.
Without kwdargs inside ``[]``, you would not be able to do this::