Skip to content

Commit 740d5da

Browse files
[3.11] gh-101100: Fix Sphinx nitpicks in library/numbers.rst (GH-113162) (#113181)
Co-authored-by: Alex Waygood <[email protected]>
1 parent 220fae7 commit 740d5da

File tree

2 files changed

+10
-10
lines changed

2 files changed

+10
-10
lines changed

Doc/library/numbers.rst

Lines changed: 10 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -8,7 +8,7 @@
88

99
--------------
1010

11-
The :mod:`numbers` module (:pep:`3141`) defines a hierarchy of numeric
11+
The :mod:`!numbers` module (:pep:`3141`) defines a hierarchy of numeric
1212
:term:`abstract base classes <abstract base class>` which progressively define
1313
more operations. None of the types defined in this module are intended to be instantiated.
1414

@@ -45,7 +45,7 @@ The numeric tower
4545

4646
.. class:: Real
4747

48-
To :class:`Complex`, :class:`Real` adds the operations that work on real
48+
To :class:`Complex`, :class:`!Real` adds the operations that work on real
4949
numbers.
5050

5151
In short, those are: a conversion to :class:`float`, :func:`math.trunc`,
@@ -126,7 +126,8 @@ We want to implement the arithmetic operations so that mixed-mode
126126
operations either call an implementation whose author knew about the
127127
types of both arguments, or convert both to the nearest built in type
128128
and do the operation there. For subtypes of :class:`Integral`, this
129-
means that :meth:`__add__` and :meth:`__radd__` should be defined as::
129+
means that :meth:`~object.__add__` and :meth:`~object.__radd__` should be
130+
defined as::
130131

131132
class MyIntegral(Integral):
132133

@@ -160,15 +161,15 @@ refer to ``MyIntegral`` and ``OtherTypeIKnowAbout`` as
160161
of :class:`Complex` (``a : A <: Complex``), and ``b : B <:
161162
Complex``. I'll consider ``a + b``:
162163

163-
1. If ``A`` defines an :meth:`__add__` which accepts ``b``, all is
164+
1. If ``A`` defines an :meth:`~object.__add__` which accepts ``b``, all is
164165
well.
165166
2. If ``A`` falls back to the boilerplate code, and it were to
166-
return a value from :meth:`__add__`, we'd miss the possibility
167-
that ``B`` defines a more intelligent :meth:`__radd__`, so the
167+
return a value from :meth:`~object.__add__`, we'd miss the possibility
168+
that ``B`` defines a more intelligent :meth:`~object.__radd__`, so the
168169
boilerplate should return :const:`NotImplemented` from
169-
:meth:`__add__`. (Or ``A`` may not implement :meth:`__add__` at
170+
:meth:`!__add__`. (Or ``A`` may not implement :meth:`!__add__` at
170171
all.)
171-
3. Then ``B``'s :meth:`__radd__` gets a chance. If it accepts
172+
3. Then ``B``'s :meth:`~object.__radd__` gets a chance. If it accepts
172173
``a``, all is well.
173174
4. If it falls back to the boilerplate, there are no more possible
174175
methods to try, so this is where the default implementation
@@ -180,7 +181,7 @@ Complex``. I'll consider ``a + b``:
180181

181182
If ``A <: Complex`` and ``B <: Real`` without sharing any other knowledge,
182183
then the appropriate shared operation is the one involving the built
183-
in :class:`complex`, and both :meth:`__radd__` s land there, so ``a+b
184+
in :class:`complex`, and both :meth:`~object.__radd__` s land there, so ``a+b
184185
== b+a``.
185186

186187
Because most of the operations on any given type will be very similar,

Doc/tools/.nitignore

Lines changed: 0 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -68,7 +68,6 @@ Doc/library/lzma.rst
6868
Doc/library/mmap.rst
6969
Doc/library/multiprocessing.rst
7070
Doc/library/multiprocessing.shared_memory.rst
71-
Doc/library/numbers.rst
7271
Doc/library/optparse.rst
7372
Doc/library/os.rst
7473
Doc/library/pickle.rst

0 commit comments

Comments
 (0)