mirror of
https://github.com/python/cpython
synced 2024-09-05 00:05:39 +00:00
gh-110631: Fix reST indentation (#110724)
* Fix wrong indentation in the other dirs. * Fix more wrong indentation.
This commit is contained in:
parent
bb7923f556
commit
718391f475
|
@ -491,18 +491,18 @@ Customize Memory Allocators
|
|||
|
||||
:c:func:`PyMem_SetAllocator` does have the following contract:
|
||||
|
||||
* It can be called after :c:func:`Py_PreInitialize` and before
|
||||
:c:func:`Py_InitializeFromConfig` to install a custom memory
|
||||
allocator. There are no restrictions over the installed allocator
|
||||
other than the ones imposed by the domain (for instance, the Raw
|
||||
Domain allows the allocator to be called without the GIL held). See
|
||||
:ref:`the section on allocator domains <allocator-domains>` for more
|
||||
information.
|
||||
* It can be called after :c:func:`Py_PreInitialize` and before
|
||||
:c:func:`Py_InitializeFromConfig` to install a custom memory
|
||||
allocator. There are no restrictions over the installed allocator
|
||||
other than the ones imposed by the domain (for instance, the Raw
|
||||
Domain allows the allocator to be called without the GIL held). See
|
||||
:ref:`the section on allocator domains <allocator-domains>` for more
|
||||
information.
|
||||
|
||||
* If called after Python has finish initializing (after
|
||||
:c:func:`Py_InitializeFromConfig` has been called) the allocator
|
||||
**must** wrap the existing allocator. Substituting the current
|
||||
allocator for some other arbitrary one is **not supported**.
|
||||
* If called after Python has finish initializing (after
|
||||
:c:func:`Py_InitializeFromConfig` has been called) the allocator
|
||||
**must** wrap the existing allocator. Substituting the current
|
||||
allocator for some other arbitrary one is **not supported**.
|
||||
|
||||
.. versionchanged:: 3.12
|
||||
All allocators must be thread-safe.
|
||||
|
|
|
@ -1156,13 +1156,14 @@ the following are true:
|
|||
There is a new boundary mechanism that controls how out-of-range / invalid
|
||||
bits are handled: ``STRICT``, ``CONFORM``, ``EJECT``, and ``KEEP``:
|
||||
|
||||
* STRICT --> raises an exception when presented with invalid values
|
||||
* CONFORM --> discards any invalid bits
|
||||
* EJECT --> lose Flag status and become a normal int with the given value
|
||||
* KEEP --> keep the extra bits
|
||||
- keeps Flag status and extra bits
|
||||
- extra bits do not show up in iteration
|
||||
- extra bits do show up in repr() and str()
|
||||
* STRICT --> raises an exception when presented with invalid values
|
||||
* CONFORM --> discards any invalid bits
|
||||
* EJECT --> lose Flag status and become a normal int with the given value
|
||||
* KEEP --> keep the extra bits
|
||||
|
||||
- keeps Flag status and extra bits
|
||||
- extra bits do not show up in iteration
|
||||
- extra bits do show up in repr() and str()
|
||||
|
||||
The default for Flag is ``STRICT``, the default for ``IntFlag`` is ``EJECT``,
|
||||
and the default for ``_convert_`` is ``KEEP`` (see ``ssl.Options`` for an
|
||||
|
|
|
@ -13,9 +13,9 @@ DTrace and SystemTap are monitoring tools, each providing a way to inspect
|
|||
what the processes on a computer system are doing. They both use
|
||||
domain-specific languages allowing a user to write scripts which:
|
||||
|
||||
- filter which processes are to be observed
|
||||
- gather data from the processes of interest
|
||||
- generate reports on the data
|
||||
- filter which processes are to be observed
|
||||
- gather data from the processes of interest
|
||||
- generate reports on the data
|
||||
|
||||
As of Python 3.6, CPython can be built with embedded "markers", also
|
||||
known as "probes", that can be observed by a DTrace or SystemTap script,
|
||||
|
@ -246,11 +246,9 @@ The output looks like this:
|
|||
|
||||
where the columns are:
|
||||
|
||||
- time in microseconds since start of script
|
||||
|
||||
- name of executable
|
||||
|
||||
- PID of process
|
||||
- time in microseconds since start of script
|
||||
- name of executable
|
||||
- PID of process
|
||||
|
||||
and the remainder indicates the call/return hierarchy as the script executes.
|
||||
|
||||
|
|
|
@ -288,9 +288,9 @@ The :mod:`csv` module defines the following classes:
|
|||
Inspecting each column, one of two key criteria will be considered to
|
||||
estimate if the sample contains a header:
|
||||
|
||||
- the second through n-th rows contain numeric values
|
||||
- the second through n-th rows contain strings where at least one value's
|
||||
length differs from that of the putative header of that column.
|
||||
- the second through n-th rows contain numeric values
|
||||
- the second through n-th rows contain strings where at least one value's
|
||||
length differs from that of the putative header of that column.
|
||||
|
||||
Twenty rows after the first row are sampled; if more than half of columns +
|
||||
rows meet the criteria, :const:`True` is returned.
|
||||
|
|
|
@ -319,13 +319,11 @@ Module contents
|
|||
module-level method (see below). Users should never instantiate a
|
||||
:class:`Field` object directly. Its documented attributes are:
|
||||
|
||||
- ``name``: The name of the field.
|
||||
|
||||
- ``type``: The type of the field.
|
||||
|
||||
- ``default``, ``default_factory``, ``init``, ``repr``, ``hash``,
|
||||
``compare``, ``metadata``, and ``kw_only`` have the identical
|
||||
meaning and values as they do in the :func:`field` function.
|
||||
- ``name``: The name of the field.
|
||||
- ``type``: The type of the field.
|
||||
- ``default``, ``default_factory``, ``init``, ``repr``, ``hash``,
|
||||
``compare``, ``metadata``, and ``kw_only`` have the identical
|
||||
meaning and values as they do in the :func:`field` function.
|
||||
|
||||
Other attributes may exist, but they are private and must not be
|
||||
inspected or relied on.
|
||||
|
|
|
@ -1396,10 +1396,10 @@ In addition to the three supplied contexts, new contexts can be created with the
|
|||
With three arguments, compute ``(x**y) % modulo``. For the three argument
|
||||
form, the following restrictions on the arguments hold:
|
||||
|
||||
- all three arguments must be integral
|
||||
- ``y`` must be nonnegative
|
||||
- at least one of ``x`` or ``y`` must be nonzero
|
||||
- ``modulo`` must be nonzero and have at most 'precision' digits
|
||||
- all three arguments must be integral
|
||||
- ``y`` must be nonnegative
|
||||
- at least one of ``x`` or ``y`` must be nonzero
|
||||
- ``modulo`` must be nonzero and have at most 'precision' digits
|
||||
|
||||
The value resulting from ``Context.power(x, y, modulo)`` is
|
||||
equal to the value that would be obtained by computing ``(x**y)
|
||||
|
|
|
@ -3795,9 +3795,9 @@ Naturally, they are all only available on Linux.
|
|||
|
||||
The file descriptor returned by :func:`timerfd_create` supports:
|
||||
|
||||
- :func:`read`
|
||||
- :func:`~select.select`
|
||||
- :func:`~select.poll`.
|
||||
- :func:`read`
|
||||
- :func:`~select.select`
|
||||
- :func:`~select.poll`
|
||||
|
||||
The file descriptor's :func:`read` method can be called with a buffer size
|
||||
of 8. If the timer has already expired one or more times, :func:`read`
|
||||
|
@ -3896,9 +3896,9 @@ Naturally, they are all only available on Linux.
|
|||
|
||||
Discontinuous system clock change will be caused by the following events:
|
||||
|
||||
- ``settimeofday``
|
||||
- ``clock_settime``
|
||||
- set the system date and time by ``date`` command
|
||||
- ``settimeofday``
|
||||
- ``clock_settime``
|
||||
- set the system date and time by ``date`` command
|
||||
|
||||
Return a two-item tuple of (``next_expiration``, ``interval``) from
|
||||
the previous timer state, before this function executed.
|
||||
|
|
|
@ -1195,21 +1195,22 @@ Otherwise, your users may experience problems using your application. Note that
|
|||
the first suggestion is the best, as the others may still be susceptible to
|
||||
non-standard paths in the registry and user site-packages.
|
||||
|
||||
.. versionchanged::
|
||||
3.6
|
||||
.. versionchanged:: 3.6
|
||||
|
||||
* Adds ``._pth`` file support and removes ``applocal`` option from
|
||||
``pyvenv.cfg``.
|
||||
* Adds :file:`python{XX}.zip` as a potential landmark when directly adjacent
|
||||
to the executable.
|
||||
Add ``._pth`` file support and removes ``applocal`` option from
|
||||
``pyvenv.cfg``.
|
||||
|
||||
.. deprecated::
|
||||
3.6
|
||||
.. versionchanged:: 3.6
|
||||
|
||||
Modules specified in the registry under ``Modules`` (not ``PythonPath``)
|
||||
may be imported by :class:`importlib.machinery.WindowsRegistryFinder`.
|
||||
This finder is enabled on Windows in 3.6.0 and earlier, but may need to
|
||||
be explicitly added to :data:`sys.meta_path` in the future.
|
||||
Add :file:`python{XX}.zip` as a potential landmark when directly adjacent
|
||||
to the executable.
|
||||
|
||||
.. deprecated:: 3.6
|
||||
|
||||
Modules specified in the registry under ``Modules`` (not ``PythonPath``)
|
||||
may be imported by :class:`importlib.machinery.WindowsRegistryFinder`.
|
||||
This finder is enabled on Windows in 3.6.0 and earlier, but may need to
|
||||
be explicitly added to :data:`sys.meta_path` in the future.
|
||||
|
||||
Additional modules
|
||||
==================
|
||||
|
|
Loading…
Reference in a new issue