8000 gh-96265: Fix some formatting in faq/design.rst by slateny · Pull Request #96924 · python/cpython · GitHub
[go: up one dir, main page]

Skip to content

gh-96265: Fix some formatting in faq/design.rst #96924

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 8 commits into from
Oct 7, 2022
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Add more proper refs
  • Loading branch information
slateny committed Sep 21, 2022
commit a7542bae13bca7b8baf64969e80e411f65291175
13 changes: 8 additions & 5 deletions Doc/faq/design.rst
Original file line number Diff line number Diff line change
Expand Up @@ -129,7 +129,7 @@ reference or call the method from a particular class. In C++, if you want to
use a method from a base class which is overridden in a derived class, you have
to use the ``::`` operator -- in Python you can write
``baseclass.methodname(self, <argument list>)``. This is particularly useful
for :meth:`__init__` methods, and in general in cases where a derived class
for :meth:`~object.__init__` methods, and in general in cases where a derived class
method wants to extend the base class method of the same name and thus has to
call the base class method somehow.

Expand Down Expand Up @@ -232,7 +232,8 @@ Similar methods exist for bytes and bytearray objects.
How fast are exceptions?
------------------------

A ``try/except`` block is extremely efficient if no exceptions are raised. Actually
A :keyword:`try`/:keyword:`except` block is extremely efficient if no exceptions
are raised. Actually
catching an exception is expensive. In versions of Python prior to 2.0 it was
common to use this idiom::

Expand Down Expand Up @@ -408,7 +409,8 @@ numbers.

Lists, on the other hand, are more like arrays in other languages. They tend to
hold a varying number of objects all of which have the same type and which are
operated on one-by-one. For example, ``os.listdir('.')`` returns a list of
operated on one-by-one. For example, :func:`os.listdir('.') <os.listdir>`
returns a list of
strings representing the files in the current directory. Functions which
operate on this output would generally not break if you added another file or
two to the directory.
Expand Down Expand Up @@ -497,7 +499,8 @@ Some unacceptable solutions that have been proposed:

There is a trick to get around this if you need to, but use it at your own risk:
You can wrap a mutable structure inside a class instance which has both a
:meth:`__eq__` and a :meth:`__hash__` method. You must then make sure that the
:meth:`~object.__eq__` and a :meth:`~object.__hash__` method.
You must then make sure that the
hash value for all such wrapper objects that reside in a dictionary (or other
hash based structure), remain fixed while the object is in the dictionary (or
other structure). ::
Expand Down Expand Up @@ -528,7 +531,7 @@ is True``) then ``hash(o1) == hash(o2)`` (ie, ``o1.__hash__() == o2.__hash__()``
regardless of whether the object is in a dictionary or not. If you fail to meet
these restrictions dictionaries and other hash based structures will misbehave.

In the case of ``ListWrapper``, whenever the wrapper object is in a dictionary the
In the case of :class:`!ListWrapper`, whenever the wrapper object is in a dictionary the
wrapped list must not change to avoid anomalies. Don't do this unless you are
prepared to think hard about the requirements and the consequences of not
meeting them correctly. Consider yourself warned.
Expand Down
0