Skip to content

Commit 0689b99

Browse files
slatenyCAM-Gerlach
andauthored
gh-96265: Formatting changes for faq/programming (#98242)
* Formatting changes for faq/programming * Add missing method formatting, use non-literal formatting * Fix sphinx warnings * Some extra formatting missed earlier * More formatting suggestions from review Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM> * Add missing colon, avoid referening external module Co-authored-by: C.A.M. Gerlach <CAM.Gerlach@Gerlach.CAM>
1 parent 898d0d9 commit 0689b99

File tree

1 file changed

+48
-39
lines changed

1 file changed

+48
-39
lines changed

Doc/faq/programming.rst

+48-39
Original file line numberDiff line numberDiff line change
@@ -25,8 +25,9 @@ Reference Manual <pdb>`. You can also write your own debugger by using the code
2525
for pdb as an example.
2626

2727
The IDLE interactive development environment, which is part of the standard
28-
Python distribution (normally available as Tools/scripts/idle), includes a
29-
graphical debugger.
28+
Python distribution (normally available as
29+
`Tools/scripts/idle3 <https://github.com/python/cpython/blob/main/Tools/scripts/idle3>`_),
30+
includes a graphical debugger.
3031

3132
PythonWin is a Python IDE that includes a GUI debugger based on pdb. The
3233
PythonWin debugger colors breakpoints and has quite a few cool features such as
@@ -78,7 +79,8 @@ set of modules required by a program and bind these modules together with a
7879
Python binary to produce a single executable.
7980

8081
One is to use the freeze tool, which is included in the Python source tree as
81-
``Tools/freeze``. It converts Python byte code to C arrays; with a C compiler you can
82+
`Tools/freeze <https://github.com/python/cpython/tree/main/Tools/freeze>`_.
83+
It converts Python byte code to C arrays; with a C compiler you can
8284
embed all your modules into a new program, which is then linked with the
8385
standard Python modules.
8486

@@ -114,7 +116,7 @@ Core Language
114116
Why am I getting an UnboundLocalError when the variable has a value?
115117
--------------------------------------------------------------------
116118

117-
It can be a surprise to get the UnboundLocalError in previously working
119+
It can be a surprise to get the :exc:`UnboundLocalError` in previously working
118120
code when it is modified by adding an assignment statement somewhere in
119121
the body of a function.
120122

@@ -123,6 +125,7 @@ This code:
123125
>>> x = 10
124126
>>> def bar():
125127
... print(x)
128+
...
126129
>>> bar()
127130
10
128131

@@ -133,7 +136,7 @@ works, but this code:
133136
... print(x)
134137
... x += 1
135138

136-
results in an UnboundLocalError:
139+
results in an :exc:`!UnboundLocalError`:
137140

138141
>>> foo()
139142
Traceback (most recent call last):
@@ -155,6 +158,7 @@ global:
155158
... global x
156159
... print(x)
157160
... x += 1
161+
...
158162
>>> foobar()
159163
10
160164

@@ -176,6 +180,7 @@ keyword:
176180
... x += 1
177181
... bar()
178182
... print(x)
183+
...
179184
>>> foo()
180185
10
181186
11
@@ -273,7 +278,7 @@ main.py::
273278
import mod
274279
print(config.x)
275280

276-
Note that using a module is also the basis for implementing the Singleton design
281+
Note that using a module is also the basis for implementing the singleton design
277282
pattern, for the same reason.
278283

279284

@@ -291,9 +296,9 @@ using multiple imports per line uses less screen space.
291296

292297
It's good practice if you import modules in the following order:
293298

294-
1. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re``
299+
1. standard library modules -- e.g. :mod:`sys`, :mod:`os`, :mod:`argparse`, :mod:`re`
295300
2. third-party library modules (anything installed in Python's site-packages
296-
directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc.
301+
directory) -- e.g. :mod:`!dateutil`, :mod:`!requests`, :mod:`!PIL.Image`
297302
3. locally developed modules
298303

299304
It is sometimes necessary to move imports to a function or class to avoid
@@ -471,7 +476,7 @@ object ``x`` refers to). After this assignment we have two objects (the ints
471476

472477
Some operations (for example ``y.append(10)`` and ``y.sort()``) mutate the
473478
object, whereas superficially similar operations (for example ``y = y + [10]``
474-
and ``sorted(y)``) create a new object. In general in Python (and in all cases
479+
and :func:`sorted(y) <sorted>`) create a new object. In general in Python (and in all cases
475480
in the standard library) a method that mutates an object will return ``None``
476481
to help avoid getting the two types of operations confused. So if you
477482
mistakenly write ``y.sort()`` thinking it will give you a sorted copy of ``y``,
@@ -644,7 +649,7 @@ Sequences can be copied by slicing::
644649
How can I find the methods or attributes of an object?
645650
------------------------------------------------------
646651

647-
For an instance x of a user-defined class, ``dir(x)`` returns an alphabetized
652+
For an instance ``x`` of a user-defined class, :func:`dir(x) <dir>` returns an alphabetized
648653
list of the names containing the instance attributes and methods and attributes
649654
defined by its class.
650655

@@ -669,9 +674,9 @@ callable. Consider the following code::
669674
<__main__.A object at 0x16D07CC>
670675

671676
Arguably the class has a name: even though it is bound to two names and invoked
672-
through the name B the created instance is still reported as an instance of
673-
class A. However, it is impossible to say whether the instance's name is a or
674-
b, since both names are bound to the same value.
677+
through the name ``B`` the created instance is still reported as an instance of
678+
class ``A``. However, it is impossible to say whether the instance's name is ``a`` or
679+
``b``, since both names are bound to the same value.
675680

676681
Generally speaking it should not be necessary for your code to "know the names"
677682
of particular values. Unless you are deliberately writing introspective
@@ -841,7 +846,7 @@ How do I get int literal attribute instead of SyntaxError?
841846
----------------------------------------------------------
842847

843848
Trying to lookup an ``int`` literal attribute in the normal manner gives
844-
a syntax error because the period is seen as a decimal point::
849+
a :exc:`SyntaxError` because the period is seen as a decimal point::
845850

846851
>>> 1.__class__
847852
File "<stdin>", line 1
@@ -887,7 +892,7 @@ leading '0' in a decimal number (except '0').
887892
How do I convert a number to a string?
888893
--------------------------------------
889894

890-
To convert, e.g., the number 144 to the string '144', use the built-in type
895+
To convert, e.g., the number ``144`` to the string ``'144'``, use the built-in type
891896
constructor :func:`str`. If you want a hexadecimal or octal representation, use
892897
the built-in functions :func:`hex` or :func:`oct`. For fancy formatting, see
893898
the :ref:`f-strings` and :ref:`formatstrings` sections,
@@ -1006,11 +1011,11 @@ Not as such.
10061011
For simple input parsing, the easiest approach is usually to split the line into
10071012
whitespace-delimited words using the :meth:`~str.split` method of string objects
10081013
and then convert decimal strings to numeric values using :func:`int` or
1009-
:func:`float`. ``split()`` supports an optional "sep" parameter which is useful
1014+
:func:`float`. :meth:`!split()` supports an optional "sep" parameter which is useful
10101015
if the line uses something other than whitespace as a separator.
10111016

10121017
For more complicated input parsing, regular expressions are more powerful
1013-
than C's :c:func:`sscanf` and better suited for the task.
1018+
than C's ``sscanf`` and better suited for the task.
10141019

10151020

10161021
What does 'UnicodeDecodeError' or 'UnicodeEncodeError' error mean?
@@ -1206,15 +1211,16 @@ difference is that a Python list can contain objects of many different types.
12061211

12071212
The ``array`` module also provides methods for creating arrays of fixed types
12081213
with compact representations, but they are slower to index than lists. Also
1209-
note that NumPy and other third party packages define array-like structures with
1214+
note that `NumPy <https://numpy.org/>`_
1215+
and other third party packages define array-like structures with
12101216
various characteristics as well.
12111217

1212-
To get Lisp-style linked lists, you can emulate cons cells using tuples::
1218+
To get Lisp-style linked lists, you can emulate *cons cells* using tuples::
12131219

12141220
lisp_list = ("like", ("this", ("example", None) ) )
12151221

12161222
If mutability is desired, you could use lists instead of tuples. Here the
1217-
analogue of lisp car is ``lisp_list[0]`` and the analogue of cdr is
1223+
analogue of a Lisp *car* is ``lisp_list[0]`` and the analogue of *cdr* is
12181224
``lisp_list[1]``. Only do this if you're sure you really need to, because it's
12191225
usually a lot slower than using Python lists.
12201226

@@ -1334,11 +1340,12 @@ that even though there was an error, the append worked::
13341340
['foo', 'item']
13351341

13361342
To see why this happens, you need to know that (a) if an object implements an
1337-
``__iadd__`` magic method, it gets called when the ``+=`` augmented assignment
1343+
:meth:`~object.__iadd__` magic method, it gets called when the ``+=`` augmented
1344+
assignment
13381345
is executed, and its return value is what gets used in the assignment statement;
1339-
and (b) for lists, ``__iadd__`` is equivalent to calling ``extend`` on the list
1346+
and (b) for lists, :meth:`!__iadd__` is equivalent to calling :meth:`~list.extend` on the list
13401347
and returning the list. That's why we say that for lists, ``+=`` is a
1341-
"shorthand" for ``list.extend``::
1348+
"shorthand" for :meth:`!list.extend`::
13421349

13431350
>>> a_list = []
13441351
>>> a_list += [1]
@@ -1363,7 +1370,7 @@ Thus, in our tuple example what is happening is equivalent to::
13631370
...
13641371
TypeError: 'tuple' object does not support item assignment
13651372

1366-
The ``__iadd__`` succeeds, and thus the list is extended, but even though
1373+
The :meth:`!__iadd__` succeeds, and thus the list is extended, but even though
13671374
``result`` points to the same object that ``a_tuple[0]`` already points to,
13681375
that final assignment still results in an error, because tuples are immutable.
13691376

@@ -1440,7 +1447,8 @@ See also :ref:`why-self`.
14401447
How do I check if an object is an instance of a given class or of a subclass of it?
14411448
-----------------------------------------------------------------------------------
14421449

1443-
Use the built-in function ``isinstance(obj, cls)``. You can check if an object
1450+
Use the built-in function :func:`isinstance(obj, cls) <isinstance>`. You can
1451+
check if an object
14441452
is an instance of any of a number of classes by providing a tuple instead of a
14451453
single class, e.g. ``isinstance(obj, (class1, class2, ...))``, and can also
14461454
check whether an object is one of Python's built-in types, e.g.
@@ -1537,21 +1545,22 @@ Here the ``UpperOut`` class redefines the ``write()`` method to convert the
15371545
argument string to uppercase before calling the underlying
15381546
``self._outfile.write()`` method. All other methods are delegated to the
15391547
underlying ``self._outfile`` object. The delegation is accomplished via the
1540-
``__getattr__`` method; consult :ref:`the language reference <attribute-access>`
1548+
:meth:`~object.__getattr__` method; consult :ref:`the language reference <attribute-access>`
15411549
for more information about controlling attribute access.
15421550

15431551
Note that for more general cases delegation can get trickier. When attributes
1544-
must be set as well as retrieved, the class must define a :meth:`__setattr__`
1552+
must be set as well as retrieved, the class must define a :meth:`~object.__setattr__`
15451553
method too, and it must do so carefully. The basic implementation of
1546-
:meth:`__setattr__` is roughly equivalent to the following::
1554+
:meth:`!__setattr__` is roughly equivalent to the following::
15471555

15481556
class X:
15491557
...
15501558
def __setattr__(self, name, value):
15511559
self.__dict__[name] = value
15521560
...
15531561

1554-
Most :meth:`__setattr__` implementations must modify ``self.__dict__`` to store
1562+
Most :meth:`!__setattr__` implementations must modify
1563+
:meth:`self.__dict__ <object.__dict__>` to store
15551564
local state for self without causing an infinite recursion.
15561565

15571566

@@ -1689,25 +1698,25 @@ My class defines __del__ but it is not called when I delete the object.
16891698

16901699
There are several possible reasons for this.
16911700

1692-
The del statement does not necessarily call :meth:`__del__` -- it simply
1701+
The :keyword:`del` statement does not necessarily call :meth:`~object.__del__` -- it simply
16931702
decrements the object's reference count, and if this reaches zero
1694-
:meth:`__del__` is called.
1703+
:meth:`!__del__` is called.
16951704

16961705
If your data structures contain circular links (e.g. a tree where each child has
16971706
a parent reference and each parent has a list of children) the reference counts
16981707
will never go back to zero. Once in a while Python runs an algorithm to detect
16991708
such cycles, but the garbage collector might run some time after the last
1700-
reference to your data structure vanishes, so your :meth:`__del__` method may be
1709+
reference to your data structure vanishes, so your :meth:`!__del__` method may be
17011710
called at an inconvenient and random time. This is inconvenient if you're trying
1702-
to reproduce a problem. Worse, the order in which object's :meth:`__del__`
1711+
to reproduce a problem. Worse, the order in which object's :meth:`!__del__`
17031712
methods are executed is arbitrary. You can run :func:`gc.collect` to force a
17041713
collection, but there *are* pathological cases where objects will never be
17051714
collected.
17061715

17071716
Despite the cycle collector, it's still a good idea to define an explicit
17081717
``close()`` method on objects to be called whenever you're done with them. The
17091718
``close()`` method can then remove attributes that refer to subobjects. Don't
1710-
call :meth:`__del__` directly -- :meth:`__del__` should call ``close()`` and
1719+
call :meth:`!__del__` directly -- :meth:`!__del__` should call ``close()`` and
17111720
``close()`` should make sure that it can be called more than once for the same
17121721
object.
17131722

@@ -1724,7 +1733,7 @@ and sibling references (if they need them!).
17241733
Normally, calling :func:`sys.exc_clear` will take care of this by clearing
17251734
the last recorded exception.
17261735
1727-
Finally, if your :meth:`__del__` method raises an exception, a warning message
1736+
Finally, if your :meth:`!__del__` method raises an exception, a warning message
17281737
is printed to :data:`sys.stderr`.
17291738

17301739

@@ -1852,8 +1861,8 @@ For example, here is the implementation of
18521861
How can a subclass control what data is stored in an immutable instance?
18531862
------------------------------------------------------------------------
18541863

1855-
When subclassing an immutable type, override the :meth:`__new__` method
1856-
instead of the :meth:`__init__` method. The latter only runs *after* an
1864+
When subclassing an immutable type, override the :meth:`~object.__new__` method
1865+
instead of the :meth:`~object.__init__` method. The latter only runs *after* an
18571866
instance is created, which is too late to alter data in an immutable
18581867
instance.
18591868

@@ -1955,8 +1964,8 @@ can't be made to work because it cannot detect changes to the
19551964
attributes.
19561965

19571966
To make the *lru_cache* approach work when the *station_id* is mutable,
1958-
the class needs to define the *__eq__* and *__hash__* methods so that
1959-
the cache can detect relevant attribute updates::
1967+
the class needs to define the :meth:`~object.__eq__` and :meth:`~object.__hash__`
1968+
methods so that the cache can detect relevant attribute updates::
19601969

19611970
class Weather:
19621971
"Example with a mutable station identifier"

0 commit comments

Comments
 (0)