-
-
Notifications
You must be signed in to change notification settings - Fork 32.1k
gh-96265: Formatting changes for faq/programming #98242
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit
Hold shift + click to select a range
8f40dcb
Formatting changes for faq/programming
slateny 85796a8
Add missing method formatting, use non-literal formatting
slateny 9112b9f
Fix sphinx warnings
slateny 522a879
Some extra formatting missed earlier
slateny cbcfa09
More formatting suggestions from review
slateny 37dacbe
Add missing colon, avoid referening external module
slateny File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Next
Next commit
Formatting changes for faq/programming
- Loading branch information
commit 8f40dcb9f3dc287f07a31a8c522e48fdb5f54f78
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -25,8 +25,9 @@ Reference Manual <pdb>`. You can also write your own debugger by using the code | |
for pdb as an example. | ||
|
||
The IDLE interactive development environment, which is part of the standard | ||
Python distribution (normally available as Tools/scripts/idle), includes a | ||
graphical debugger. | ||
Python distribution (normally available as | ||
`Tools/scripts/idle3 <https://github.com/python/cpython/blob/main/Tools/scripts/idle3>`_), | ||
includes a graphical debugger. | ||
|
||
PythonWin is a Python IDE that includes a GUI debugger based on pdb. The | ||
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 | |
Python binary to produce a single executable. | ||
|
||
One is to use the freeze tool, which is included in the Python source tree as | ||
``Tools/freeze``. It converts Python byte code to C arrays; with a C compiler you can | ||
`Tools/freeze <https://github.com/python/cpython/tree/main/Tools/freeze>`_. | ||
It converts Python byte code to C arrays; with a C compiler you can | ||
embed all your modules into a new program, which is then linked with the | ||
standard Python modules. | ||
|
||
|
@@ -114,7 +116,7 @@ Core Language | |
Why am I getting an UnboundLocalError when the variable has a value? | ||
-------------------------------------------------------------------- | ||
|
||
It can be a surprise to get the UnboundLocalError in previously working | ||
It can be a surprise to get the :exc:`UnboundLocalError` in previously working | ||
code when it is modified by adding an assignment statement somewhere in | ||
the body of a function. | ||
|
||
|
@@ -123,6 +125,7 @@ This code: | |
>>> x = 10 | ||
>>> def bar(): | ||
... print(x) | ||
... | ||
>>> bar() | ||
10 | ||
|
||
|
@@ -133,7 +136,7 @@ works, but this code: | |
... print(x) | ||
... x += 1 | ||
|
||
results in an UnboundLocalError: | ||
results in an ``UnboundLocalError``: | ||
|
||
>>> foo() | ||
Traceback (most recent call last): | ||
|
@@ -155,6 +158,7 @@ global: | |
... global x | ||
... print(x) | ||
... x += 1 | ||
... | ||
>>> foobar() | ||
10 | ||
|
||
|
@@ -176,6 +180,7 @@ keyword: | |
... x += 1 | ||
... bar() | ||
... print(x) | ||
... | ||
>>> foo() | ||
10 | ||
11 | ||
|
@@ -273,7 +278,7 @@ main.py:: | |
import mod | ||
print(config.x) | ||
|
||
Note that using a module is also the basis for implementing the Singleton design | ||
Note that using a module is also the basis for implementing the singleton design | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change was not useful: classic design patterns are commonly title cased. |
||
pattern, for the same reason. | ||
|
||
|
||
|
@@ -293,7 +298,7 @@ It's good practice if you import modules in the following order: | |
|
||
1. standard library modules -- e.g. ``sys``, ``os``, ``getopt``, ``re`` | ||
slateny marked this conversation as resolved.
Show resolved
Hide resolved
|
||
2. third-party library modules (anything installed in Python's site-packages | ||
directory) -- e.g. mx.DateTime, ZODB, PIL.Image, etc. | ||
directory) -- e.g. ``mx.DateTime``, ``ZODB``, ``PIL.Image`` | ||
slateny marked this conversation as resolved.
Show resolved
Hide resolved
|
||
3. locally developed modules | ||
|
||
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 | |
|
||
Some operations (for example ``y.append(10)`` and ``y.sort()``) mutate the | ||
object, whereas superficially similar operations (for example ``y = y + [10]`` | ||
and ``sorted(y)``) create a new object. In general in Python (and in all cases | ||
and :func:`sorted(y) <sorted>`) create a new object. In general in Python (and in all cases | ||
in the standard library) a method that mutates an object will return ``None`` | ||
to help avoid getting the two types of operations confused. So if you | ||
mistakenly write ``y.sort()`` thinking it will give you a sorted copy of ``y``, | ||
|
@@ -644,7 +649,7 @@ Sequences can be copied by slicing:: | |
How can I find the methods or attributes of an object? | ||
------------------------------------------------------ | ||
|
||
For an instance x of a user-defined class, ``dir(x)`` returns an alphabetized | ||
For an instance ``x`` of a user-defined class, :func:`dir(x) <dir>` returns an alphabetized | ||
list of the names containing the instance attributes and methods and attributes | ||
defined by its class. | ||
|
||
|
@@ -669,9 +674,9 @@ callable. Consider the following code:: | |
<__main__.A object at 0x16D07CC> | ||
|
||
Arguably the class has a name: even though it is bound to two names and invoked | ||
through the name B the created instance is still reported as an instance of | ||
class A. However, it is impossible to say whether the instance's name is a or | ||
b, since both names are bound to the same value. | ||
through the name ``B`` the created instance is still reported as an instance of | ||
class ``A``. However, it is impossible to say whether the instance's name is ``a`` or | ||
``b``, since both names are bound to the same value. | ||
|
||
Generally speaking it should not be necessary for your code to "know the names" | ||
of particular values. Unless you are deliberately writing introspective | ||
|
@@ -841,7 +846,7 @@ How do I get int literal attribute instead of SyntaxError? | |
---------------------------------------------------------- | ||
|
||
Trying to lookup an ``int`` literal attribute in the normal manner gives | ||
a syntax error because the period is seen as a decimal point:: | ||
a :exc:`SyntaxError` because the period is seen as a decimal point:: | ||
|
||
>>> 1.__class__ | ||
File "<stdin>", line 1 | ||
|
@@ -887,7 +892,7 @@ leading '0' in a decimal number (except '0'). | |
How do I convert a number to a string? | ||
-------------------------------------- | ||
|
||
To convert, e.g., the number 144 to the string '144', use the built-in type | ||
To convert, e.g., the number ``144`` to the string ``'144'``, use the built-in type | ||
constructor :func:`str`. If you want a hexadecimal or octal representation, use | ||
the built-in functions :func:`hex` or :func:`oct`. For fancy formatting, see | ||
the :ref:`f-strings` and :ref:`formatstrings` sections, | ||
|
@@ -1206,15 +1211,16 @@ difference is that a Python list can contain objects of many different types. | |
|
||
The ``array`` module also provides methods for creating arrays of fixed types | ||
with compact representations, but they are slower to index than lists. Also | ||
note that NumPy and other third party packages define array-like structures with | ||
note that `NumPy <https://numpy.org/>`_ | ||
and other third party packages define array-like structures with | ||
various characteristics as well. | ||
|
||
To get Lisp-style linked lists, you can emulate cons cells using tuples:: | ||
To get Lisp-style linked lists, you can emulate *cons cells* using tuples:: | ||
|
||
lisp_list = ("like", ("this", ("example", None) ) ) | ||
|
||
If mutability is desired, you could use lists instead of tuples. Here the | ||
analogue of lisp car is ``lisp_list[0]`` and the analogue of cdr is | ||
analogue of a Lisp *car* is ``lisp_list[0]`` and the analogue of *cdr* is | ||
``lisp_list[1]``. Only do this if you're sure you really need to, because it's | ||
usually a lot slower than using Python lists. | ||
|
||
|
@@ -1689,7 +1695,7 @@ My class defines __del__ but it is not called when I delete the object. | |
|
||
There are several possible reasons for this. | ||
|
||
The del statement does not necessarily call :meth:`__del__` -- it simply | ||
The :keyword:`del` statement does not necessarily call :meth:`~object.__del__` -- it simply | ||
decrements the object's reference count, and if this reaches zero | ||
:meth:`__del__` is called. | ||
slateny marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
|
@@ -1852,8 +1858,8 @@ For example, here is the implementation of | |
How can a subclass control what data is stored in an immutable instance? | ||
------------------------------------------------------------------------ | ||
|
||
When subclassing an immutable type, override the :meth:`__new__` method | ||
instead of the :meth:`__init__` method. The latter only runs *after* an | ||
When subclassing an immutable type, override the :meth:`~object.__new__` method | ||
instead of the :meth:`~object.__init__` method. The latter only runs *after* an | ||
instance is created, which is too late to alter data in an immutable | ||
instance. | ||
|
||
|
@@ -1955,8 +1961,8 @@ can't be made to work because it cannot detect changes to the | |
attributes. | ||
|
||
To make the *lru_cache* approach work when the *station_id* is mutable, | ||
the class needs to define the *__eq__* and *__hash__* methods so that | ||
the cache can detect relevant attribute updates:: | ||
the class needs to define the :meth:`~object.__eq__` and :meth:`~object.__hash__` | ||
methods so that the cache can detect relevant attribute updates:: | ||
|
||
class Weather: | ||
"Example with a mutable station identifier" | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.