mirror of https://github.com/python/cpython
docs: fix a few typos identified by codespell (#119516)
This commit is contained in:
parent
e418fc3a6e
commit
d25954dff5
|
@ -35,7 +35,7 @@ as much as it can.
|
|||
callable object that receives notification when *ob* is garbage collected; it
|
||||
should accept a single parameter, which will be the weak reference object
|
||||
itself. *callback* may also be ``None`` or ``NULL``. If *ob* is not a
|
||||
weakly referencable object, or if *callback* is not callable, ``None``, or
|
||||
weakly referenceable object, or if *callback* is not callable, ``None``, or
|
||||
``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
|
||||
|
||||
|
||||
|
@ -47,7 +47,7 @@ as much as it can.
|
|||
be a callable object that receives notification when *ob* is garbage
|
||||
collected; it should accept a single parameter, which will be the weak
|
||||
reference object itself. *callback* may also be ``None`` or ``NULL``. If *ob*
|
||||
is not a weakly referencable object, or if *callback* is not callable,
|
||||
is not a weakly referenceable object, or if *callback* is not callable,
|
||||
``None``, or ``NULL``, this will return ``NULL`` and raise :exc:`TypeError`.
|
||||
|
||||
|
||||
|
|
|
@ -868,7 +868,7 @@ It is important to call :c:func:`free` at the right time. If a block's address
|
|||
is forgotten but :c:func:`free` is not called for it, the memory it occupies
|
||||
cannot be reused until the program terminates. This is called a :dfn:`memory
|
||||
leak`. On the other hand, if a program calls :c:func:`free` for a block and then
|
||||
continues to use the block, it creates a conflict with re-use of the block
|
||||
continues to use the block, it creates a conflict with reuse of the block
|
||||
through another :c:func:`malloc` call. This is called :dfn:`using freed memory`.
|
||||
It has the same bad consequences as referencing uninitialized data --- core
|
||||
dumps, wrong results, mysterious crashes.
|
||||
|
|
|
@ -545,7 +545,7 @@ performance-critical objects (such as numbers).
|
|||
.. seealso::
|
||||
Documentation for the :mod:`weakref` module.
|
||||
|
||||
For an object to be weakly referencable, the extension type must set the
|
||||
For an object to be weakly referenceable, the extension type must set the
|
||||
``Py_TPFLAGS_MANAGED_WEAKREF`` bit of the :c:member:`~PyTypeObject.tp_flags`
|
||||
field. The legacy :c:member:`~PyTypeObject.tp_weaklistoffset` field should
|
||||
be left as zero.
|
||||
|
|
|
@ -426,7 +426,7 @@ In this case the MRO is GFEF and the local precedence ordering is
|
|||
preserved.
|
||||
|
||||
As a general rule, hierarchies such as the previous one should be
|
||||
avoided, since it is unclear if F should override E or viceversa.
|
||||
avoided, since it is unclear if F should override E or vice-versa.
|
||||
Python 2.3 solves the ambiguity by raising an exception in the creation
|
||||
of class G, effectively stopping the programmer from generating
|
||||
ambiguous hierarchies. The reason for that is that the C3 algorithm
|
||||
|
|
|
@ -924,7 +924,7 @@ the following methods and attributes:
|
|||
|
||||
.. method:: window.getbegyx()
|
||||
|
||||
Return a tuple ``(y, x)`` of co-ordinates of upper-left corner.
|
||||
Return a tuple ``(y, x)`` of coordinates of upper-left corner.
|
||||
|
||||
|
||||
.. method:: window.getbkgd()
|
||||
|
|
|
@ -84,10 +84,10 @@ The numeric tower
|
|||
``~``.
|
||||
|
||||
|
||||
Notes for type implementors
|
||||
Notes for type implementers
|
||||
---------------------------
|
||||
|
||||
Implementors should be careful to make equal numbers equal and hash
|
||||
Implementers should be careful to make equal numbers equal and hash
|
||||
them to the same values. This may be subtle if there are two different
|
||||
extensions of the real numbers. For example, :class:`fractions.Fraction`
|
||||
implements :func:`hash` as follows::
|
||||
|
|
|
@ -1739,7 +1739,7 @@ seen, but blow up if it comes after ``-b`` in the command-line. ::
|
|||
Callback example 3: check option order (generalized)
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
If you want to re-use this callback for several similar options (set a flag, but
|
||||
If you want to reuse this callback for several similar options (set a flag, but
|
||||
blow up if ``-b`` has already been seen), it needs a bit of work: the error
|
||||
message and the flag that it sets must be generalized. ::
|
||||
|
||||
|
|
|
@ -781,7 +781,7 @@ Constants
|
|||
|
||||
.. data:: OP_SINGLE_DH_USE
|
||||
|
||||
Prevents re-use of the same DH key for distinct SSL sessions. This
|
||||
Prevents reuse of the same DH key for distinct SSL sessions. This
|
||||
improves forward secrecy but requires more computational resources.
|
||||
This option only applies to server sockets.
|
||||
|
||||
|
@ -789,7 +789,7 @@ Constants
|
|||
|
||||
.. data:: OP_SINGLE_ECDH_USE
|
||||
|
||||
Prevents re-use of the same ECDH key for distinct SSL sessions. This
|
||||
Prevents reuse of the same ECDH key for distinct SSL sessions. This
|
||||
improves forward secrecy but requires more computational resources.
|
||||
This option only applies to server sockets.
|
||||
|
||||
|
|
|
@ -154,7 +154,7 @@ hyphenated words; only then will long words be broken if necessary, unless
|
|||
wrapper = TextWrapper()
|
||||
wrapper.initial_indent = "* "
|
||||
|
||||
You can re-use the same :class:`TextWrapper` object many times, and you can
|
||||
You can reuse the same :class:`TextWrapper` object many times, and you can
|
||||
change any of its options through direct assignment to instance attributes
|
||||
between uses.
|
||||
|
||||
|
|
|
@ -120,7 +120,7 @@ off-screen)::
|
|||
home()
|
||||
|
||||
The home position is at the center of the turtle's screen. If you ever need to
|
||||
know them, get the turtle's x-y co-ordinates with::
|
||||
know them, get the turtle's x-y coordinates with::
|
||||
|
||||
pos()
|
||||
|
||||
|
|
|
@ -38,7 +38,7 @@ Creating Virtual Environments
|
|||
The module used to create and manage virtual environments is called
|
||||
:mod:`venv`. :mod:`venv` will install the Python version from which
|
||||
the command was run (as reported by the :option:`--version` option).
|
||||
For instance, excuting the command with ``python3.12`` will install
|
||||
For instance, executing the command with ``python3.12`` will install
|
||||
version 3.12.
|
||||
|
||||
To create a virtual environment, decide upon a directory where you want to
|
||||
|
|
|
@ -303,8 +303,8 @@ modules in your app, some additional steps will be required:
|
|||
* You need to ensure that any folders containing third-party binaries are
|
||||
either associated with the app target, or copied in as part of step 8. Step 8
|
||||
should also purge any binaries that are not appropriate for the platform a
|
||||
specific build is targetting (i.e., delete any device binaries if you're
|
||||
building app app targeting the simulator).
|
||||
specific build is targeting (i.e., delete any device binaries if you're
|
||||
building an app targeting the simulator).
|
||||
|
||||
* Any folders that contain third-party binaries must be processed into
|
||||
framework form by step 9. The invocation of ``install_dylib`` that processes
|
||||
|
|
|
@ -1062,7 +1062,7 @@ code, none of the changes described here will affect you very much.
|
|||
simply been changed to use the new C-level interface. (Contributed by Fred L.
|
||||
Drake, Jr.)
|
||||
|
||||
* Another low-level API, primarily of interest to implementors of Python
|
||||
* Another low-level API, primarily of interest to implementers of Python
|
||||
debuggers and development tools, was added. :c:func:`PyInterpreterState_Head` and
|
||||
:c:func:`PyInterpreterState_Next` let a caller walk through all the existing
|
||||
interpreter objects; :c:func:`PyInterpreterState_ThreadHead` and
|
||||
|
|
|
@ -1738,7 +1738,7 @@ New module: importlib
|
|||
|
||||
Python 3.1 includes the :mod:`importlib` package, a re-implementation
|
||||
of the logic underlying Python's :keyword:`import` statement.
|
||||
:mod:`importlib` is useful for implementors of Python interpreters and
|
||||
:mod:`importlib` is useful for implementers of Python interpreters and
|
||||
to users who wish to write new importers that can participate in the
|
||||
import process. Python 2.7 doesn't contain the complete
|
||||
:mod:`importlib` package, but instead has a tiny subset that contains
|
||||
|
|
|
@ -1251,7 +1251,7 @@ Deprecated
|
|||
:exc:`DeprecationWarning` when it can detect being called from a
|
||||
multithreaded process. There has always been a fundamental incompatibility
|
||||
with the POSIX platform when doing so. Even if such code *appeared* to work.
|
||||
We added the warning to to raise awareness as issues encounted by code doing
|
||||
We added the warning to raise awareness as issues encountered by code doing
|
||||
this are becoming more frequent. See the :func:`os.fork` documentation for
|
||||
more details along with `this discussion on fork being incompatible with threads
|
||||
<https://discuss.python.org/t/33555>`_ for *why* we're now surfacing this
|
||||
|
|
|
@ -2413,7 +2413,7 @@ Changes in the Python API
|
|||
formal public interface the naming has been made consistent (:issue:`18532`).
|
||||
|
||||
* Because :mod:`unittest.TestSuite` now drops references to tests after they
|
||||
are run, test harnesses that re-use a :class:`~unittest.TestSuite` to re-run
|
||||
are run, test harnesses that reuse a :class:`~unittest.TestSuite` to re-run
|
||||
a set of tests may fail. Test suites should not be re-used in this fashion
|
||||
since it means state is retained between test runs, breaking the test
|
||||
isolation that :mod:`unittest` is designed to provide. However, if the lack
|
||||
|
|
|
@ -2336,10 +2336,10 @@ Changes in the Python API
|
|||
* With the introduction of :exc:`ModuleNotFoundError`, import system consumers
|
||||
may start expecting import system replacements to raise that more specific
|
||||
exception when appropriate, rather than the less-specific :exc:`ImportError`.
|
||||
To provide future compatibility with such consumers, implementors of
|
||||
To provide future compatibility with such consumers, implementers of
|
||||
alternative import systems that completely replace :func:`__import__` will
|
||||
need to update their implementations to raise the new subclass when a module
|
||||
can't be found at all. Implementors of compliant plugins to the default
|
||||
can't be found at all. Implementers of compliant plugins to the default
|
||||
import system shouldn't need to make any changes, as the default import
|
||||
system will raise the new subclass when appropriate.
|
||||
|
||||
|
|
|
@ -891,7 +891,7 @@ Deprecated
|
|||
|
||||
* Deprecated the ``split()`` method of :class:`!_tkinter.TkappType` in
|
||||
favour of the ``splitlist()`` method which has more consistent and
|
||||
predicable behavior.
|
||||
predictable behavior.
|
||||
(Contributed by Serhiy Storchaka in :issue:`38371`.)
|
||||
|
||||
* The explicit passing of coroutine objects to :func:`asyncio.wait` has been
|
||||
|
|
Loading…
Reference in New Issue