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`.
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`.
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.
.. 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.
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
.. 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()
``~``.
-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::
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. ::
.. 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.
.. 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.
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.
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()
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
* 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
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
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
: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
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
* 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.
* 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
projects / thirdparty / Python / cpython.git / commitdiff
