mirror of
https://github.com/python/cpython.git
synced 2025-09-26 10:19:53 +00:00
[3.12] gh-101100: Fix sphinx warnings in threading.rst
(GH-108684) (#108707)
gh-101100: Fix sphinx warnings in `threading.rst` (GH-108684)
(cherry picked from commit 991e4e76b5
)
Co-authored-by: Nikita Sobolev <mail@sobolevn.me>
Co-authored-by: Hugo van Kemenade <hugovk@users.noreply.github.com>
This commit is contained in:
parent
1a15d20b75
commit
bc42d6c604
2 changed files with 8 additions and 9 deletions
|
@ -272,7 +272,7 @@ The instance's values will be different for separate threads.
|
|||
A class that represents thread-local data.
|
||||
|
||||
For more details and extensive examples, see the documentation string of the
|
||||
:mod:`_threading_local` module: :source:`Lib/_threading_local.py`.
|
||||
:mod:`!_threading_local` module: :source:`Lib/_threading_local.py`.
|
||||
|
||||
|
||||
.. _thread-objects:
|
||||
|
@ -285,7 +285,7 @@ thread of control. There are two ways to specify the activity: by passing a
|
|||
callable object to the constructor, or by overriding the :meth:`~Thread.run`
|
||||
method in a subclass. No other methods (except for the constructor) should be
|
||||
overridden in a subclass. In other words, *only* override the
|
||||
:meth:`~Thread.__init__` and :meth:`~Thread.run` methods of this class.
|
||||
``__init__()`` and :meth:`~Thread.run` methods of this class.
|
||||
|
||||
Once a thread object is created, its activity must be started by calling the
|
||||
thread's :meth:`~Thread.start` method. This invokes the :meth:`~Thread.run`
|
||||
|
@ -337,7 +337,7 @@ since it is impossible to detect the termination of alien threads.
|
|||
are:
|
||||
|
||||
*group* should be ``None``; reserved for future extension when a
|
||||
:class:`ThreadGroup` class is implemented.
|
||||
:class:`!ThreadGroup` class is implemented.
|
||||
|
||||
*target* is the callable object to be invoked by the :meth:`run` method.
|
||||
Defaults to ``None``, meaning nothing is called.
|
||||
|
@ -1009,7 +1009,7 @@ This class represents an action that should be run only after a certain amount
|
|||
of time has passed --- a timer. :class:`Timer` is a subclass of :class:`Thread`
|
||||
and as such also functions as an example of creating custom threads.
|
||||
|
||||
Timers are started, as with threads, by calling their :meth:`~Timer.start`
|
||||
Timers are started, as with threads, by calling their :meth:`Timer.start <Thread.start>`
|
||||
method. The timer can be stopped (before its action has begun) by calling the
|
||||
:meth:`~Timer.cancel` method. The interval the timer will wait before
|
||||
executing its action may not be exactly the same as the interval specified by
|
||||
|
@ -1147,10 +1147,10 @@ As an example, here is a simple way to synchronize a client and server thread::
|
|||
Using locks, conditions, and semaphores in the :keyword:`!with` statement
|
||||
-------------------------------------------------------------------------
|
||||
|
||||
All of the objects provided by this module that have :meth:`acquire` and
|
||||
:meth:`release` methods can be used as context managers for a :keyword:`with`
|
||||
statement. The :meth:`acquire` method will be called when the block is
|
||||
entered, and :meth:`release` will be called when the block is exited. Hence,
|
||||
All of the objects provided by this module that have ``acquire`` and
|
||||
``release`` methods can be used as context managers for a :keyword:`with`
|
||||
statement. The ``acquire`` method will be called when the block is
|
||||
entered, and ``release`` will be called when the block is exited. Hence,
|
||||
the following snippet::
|
||||
|
||||
with some_lock:
|
||||
|
|
|
@ -137,7 +137,6 @@ Doc/library/telnetlib.rst
|
|||
Doc/library/tempfile.rst
|
||||
Doc/library/termios.rst
|
||||
Doc/library/test.rst
|
||||
Doc/library/threading.rst
|
||||
Doc/library/time.rst
|
||||
Doc/library/tkinter.rst
|
||||
Doc/library/tkinter.scrolledtext.rst
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue