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:
Geoffrey Thomas 2024-05-22 12:35:18 -04:00 committed by GitHub
parent 81865002ae
commit ef172521a9
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
39 changed files with 172 additions and 172 deletions

View file

@ -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 *

View file

@ -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.