Extending Python Doc minor updates (GH-4518)
authorEmanuele Gaifas <lelegaifax@gmail.com>
Fri, 24 Nov 2017 08:49:57 +0000 (09:49 +0100)
committerMariatta <Mariatta@users.noreply.github.com>
Fri, 24 Nov 2017 08:49:57 +0000 (00:49 -0800)
Move footnote markers to be closer to the related terminology:
before the end of the sentence, instead of after.

Doc/extending/extending.rst
Doc/extending/newtypes.rst

index 7c273533aba5b53401d7b9fb24399e5444634abb..ea1c29a397ed86ee3177392d3dee3e80dd10abfd 100644 (file)
@@ -40,7 +40,7 @@ A Simple Example
 
 Let's create an extension module called ``spam`` (the favorite food of Monty
 Python fans...) and let's say we want to create a Python interface to the C
-library function :c:func:`system`. [#]_ This function takes a null-terminated
+library function :c:func:`system` [#]_. This function takes a null-terminated
 character string as argument and returns an integer.  We want this function to
 be callable from Python as follows::
 
@@ -917,7 +917,7 @@ It is also possible to :dfn:`borrow` [#]_ a reference to an object.  The
 borrower of a reference should not call :c:func:`Py_DECREF`.  The borrower must
 not hold on to the object longer than the owner from which it was borrowed.
 Using a borrowed reference after the owner has disposed of it risks using freed
-memory and should be avoided completely. [#]_
+memory and should be avoided completely [#]_.
 
 The advantage of borrowing over owning a reference is that you don't need to
 take care of disposing of the reference on all possible paths through the code
@@ -1088,7 +1088,7 @@ checking.
 
 The C function calling mechanism guarantees that the argument list passed to C
 functions (``args`` in the examples) is never *NULL* --- in fact it guarantees
-that it is always a tuple. [#]_
+that it is always a tuple [#]_.
 
 It is a severe error to ever let a *NULL* pointer "escape" to the Python user.
 
index 0e36ba0aec07ae1c2d6c05c46425797ff12bb709..62fbdb87a530007ec78050e1a82b8990a20ad1e6 100644 (file)
@@ -659,7 +659,7 @@ Fortunately, Python's cyclic-garbage collector will eventually figure out that
 the list is garbage and free it.
 
 In the second version of the :class:`Noddy` example, we allowed any kind of
-object to be stored in the :attr:`first` or :attr:`last` attributes. [#]_ This
+object to be stored in the :attr:`first` or :attr:`last` attributes [#]_. This
 means that :class:`Noddy` objects can participate in cycles::
 
    >>> import noddy2