mirror of
https://github.com/python/cpython.git
synced 2025-09-26 10:19:53 +00:00
Use "impl-detail" directive where applicable.
This commit is contained in:
parent
3954d21cc5
commit
6c14e587f5
13 changed files with 114 additions and 84 deletions
|
@ -56,13 +56,16 @@ Objects are never explicitly destroyed; however, when they become unreachable
|
|||
they may be garbage-collected. An implementation is allowed to postpone garbage
|
||||
collection or omit it altogether --- it is a matter of implementation quality
|
||||
how garbage collection is implemented, as long as no objects are collected that
|
||||
are still reachable. (Implementation note: CPython currently uses a
|
||||
reference-counting scheme with (optional) delayed detection of cyclically linked
|
||||
garbage, which collects most objects as soon as they become unreachable, but is
|
||||
not guaranteed to collect garbage containing circular references. See the
|
||||
documentation of the :mod:`gc` module for information on controlling the
|
||||
collection of cyclic garbage. Other implementations act differently and CPython
|
||||
may change.)
|
||||
are still reachable.
|
||||
|
||||
.. impl-detail::
|
||||
|
||||
CPython currently uses a reference-counting scheme with (optional) delayed
|
||||
detection of cyclically linked garbage, which collects most objects as soon
|
||||
as they become unreachable, but is not guaranteed to collect garbage
|
||||
containing circular references. See the documentation of the :mod:`gc`
|
||||
module for information on controlling the collection of cyclic garbage.
|
||||
Other implementations act differently and CPython may change.
|
||||
|
||||
Note that the use of the implementation's tracing or debugging facilities may
|
||||
keep objects alive that would normally be collectable. Also note that catching
|
||||
|
|
|
@ -128,7 +128,7 @@ the built-in module :mod:`__builtin__` (note: no 's'); when in any other module,
|
|||
itself. ``__builtins__`` can be set to a user-created dictionary to create a
|
||||
weak form of restricted execution.
|
||||
|
||||
.. note::
|
||||
.. impl-detail::
|
||||
|
||||
Users should not touch ``__builtins__``; it is strictly an implementation
|
||||
detail. Users wanting to override values in the built-in namespace should
|
||||
|
|
|
@ -663,13 +663,13 @@ slots for which no default value is specified, a :exc:`TypeError` exception is
|
|||
raised. Otherwise, the list of filled slots is used as the argument list for
|
||||
the call.
|
||||
|
||||
.. note::
|
||||
.. impl-detail::
|
||||
|
||||
An implementation may provide built-in functions whose positional parameters do
|
||||
not have names, even if they are 'named' for the purpose of documentation, and
|
||||
which therefore cannot be supplied by keyword. In CPython, this is the case for
|
||||
functions implemented in C that use :cfunc:`PyArg_ParseTuple` to parse their
|
||||
arguments.
|
||||
An implementation may provide built-in functions whose positional parameters
|
||||
do not have names, even if they are 'named' for the purpose of documentation,
|
||||
and which therefore cannot be supplied by keyword. In CPython, this is the
|
||||
case for functions implemented in C that use :cfunc:`PyArg_ParseTuple` to
|
||||
parse their arguments.
|
||||
|
||||
If there are more positional arguments than there are formal parameter slots, a
|
||||
:exc:`TypeError` exception is raised, unless a formal parameter using the syntax
|
||||
|
|
|
@ -219,9 +219,11 @@ Assignment of an object to a single target is recursively defined as follows.
|
|||
the length of the assigned sequence, thus changing the length of the target
|
||||
sequence, if the object allows it.
|
||||
|
||||
(In the current implementation, the syntax for targets is taken to be the same
|
||||
as for expressions, and invalid syntax is rejected during the code generation
|
||||
phase, causing less detailed error messages.)
|
||||
.. impl-detail::
|
||||
|
||||
In the current implementation, the syntax for targets is taken to be the same
|
||||
as for expressions, and invalid syntax is rejected during the code generation
|
||||
phase, causing less detailed error messages.
|
||||
|
||||
WARNING: Although the definition of assignment implies that overlaps between the
|
||||
left-hand side and the right-hand side are 'safe' (for example ``a, b = b, a``
|
||||
|
@ -946,9 +948,11 @@ Names listed in a :keyword:`global` statement must not be defined as formal
|
|||
parameters or in a :keyword:`for` loop control target, :keyword:`class`
|
||||
definition, function definition, or :keyword:`import` statement.
|
||||
|
||||
(The current implementation does not enforce the latter two restrictions, but
|
||||
programs should not abuse this freedom, as future implementations may enforce
|
||||
them or silently change the meaning of the program.)
|
||||
.. impl-detail::
|
||||
|
||||
The current implementation does not enforce the latter two restrictions, but
|
||||
programs should not abuse this freedom, as future implementations may enforce
|
||||
them or silently change the meaning of the program.
|
||||
|
||||
.. index::
|
||||
statement: exec
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue