mirror of
https://github.com/python/cpython.git
synced 2025-08-03 16:39:00 +00:00
Remove almost all unpaired backticks in docstrings (#119231)
As reported in #117847 and #115366, an unpaired backtick in a docstring tends to confuse e.g. Sphinx running on subclasses of standard library objects, and the typographic style of using a backtick as an opening quote is no longer in favor. Convert almost all uses of the form The variable `foo' should do xyz to The variable 'foo' should do xyz and also fix up miscellaneous other unpaired backticks (extraneous / missing characters). No functional change is intended here other than in human-readable docstrings.
This commit is contained in:
parent
81865002ae
commit
ef172521a9
39 changed files with 172 additions and 172 deletions
|
@ -52,25 +52,25 @@ static inline PyObject* bytes_get_empty(void)
|
|||
|
||||
|
||||
/*
|
||||
For PyBytes_FromString(), the parameter `str' points to a null-terminated
|
||||
string containing exactly `size' bytes.
|
||||
For PyBytes_FromString(), the parameter 'str' points to a null-terminated
|
||||
string containing exactly 'size' bytes.
|
||||
|
||||
For PyBytes_FromStringAndSize(), the parameter `str' is
|
||||
either NULL or else points to a string containing at least `size' bytes.
|
||||
For PyBytes_FromStringAndSize(), the string in the `str' parameter does
|
||||
For PyBytes_FromStringAndSize(), the parameter 'str' is
|
||||
either NULL or else points to a string containing at least 'size' bytes.
|
||||
For PyBytes_FromStringAndSize(), the string in the 'str' parameter does
|
||||
not have to be null-terminated. (Therefore it is safe to construct a
|
||||
substring by calling `PyBytes_FromStringAndSize(origstring, substrlen)'.)
|
||||
If `str' is NULL then PyBytes_FromStringAndSize() will allocate `size+1'
|
||||
substring by calling 'PyBytes_FromStringAndSize(origstring, substrlen)'.)
|
||||
If 'str' is NULL then PyBytes_FromStringAndSize() will allocate 'size+1'
|
||||
bytes (setting the last byte to the null terminating character) and you can
|
||||
fill in the data yourself. If `str' is non-NULL then the resulting
|
||||
fill in the data yourself. If 'str' is non-NULL then the resulting
|
||||
PyBytes object must be treated as immutable and you must not fill in nor
|
||||
alter the data yourself, since the strings may be shared.
|
||||
|
||||
The PyObject member `op->ob_size', which denotes the number of "extra
|
||||
The PyObject member 'op->ob_size', which denotes the number of "extra
|
||||
items" in a variable-size object, will contain the number of bytes
|
||||
allocated for string data, not counting the null terminating character.
|
||||
It is therefore equal to the `size' parameter (for
|
||||
PyBytes_FromStringAndSize()) or the length of the string in the `str'
|
||||
It is therefore equal to the 'size' parameter (for
|
||||
PyBytes_FromStringAndSize()) or the length of the string in the 'str'
|
||||
parameter (for PyBytes_FromString()).
|
||||
*/
|
||||
static PyObject *
|
||||
|
|
|
@ -200,7 +200,7 @@ Here are some ways to address this challenge:
|
|||
Adding the checks to the concrete API would help make any interpreter
|
||||
switch to OrderedDict less painful for extension modules. However, this
|
||||
won't work. The equivalent C API call to `dict.__setitem__(obj, k, v)`
|
||||
is 'PyDict_SetItem(obj, k, v)`. This illustrates how subclasses in C call
|
||||
is `PyDict_SetItem(obj, k, v)`. This illustrates how subclasses in C call
|
||||
the base class's methods, since there is no equivalent of super() in the
|
||||
C API. Calling into Python for parent class API would work, but some
|
||||
extension modules already rely on this feature of the concrete API.
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue