#22613: fix several factual errors in builtin docs (thanks Jacques Ducasse)
This commit is contained in:
parent
f0d2ed73ac
commit
e4196d3f2e
|
@ -34,7 +34,8 @@ class or one of its subclasses, and not from :exc:`BaseException`. More
|
|||
information on defining exceptions is available in the Python Tutorial under
|
||||
:ref:`tut-userexceptions`.
|
||||
|
||||
When raising (or re-raising) an exception in an :keyword:`except` clause
|
||||
When raising (or re-raising) an exception in an :keyword:`except` or
|
||||
:keyword:`finally` clause
|
||||
:attr:`__context__` is automatically set to the last exception caught; if the
|
||||
new exception is not handled the traceback that is eventually displayed will
|
||||
include the originating exception(s) and the final exception.
|
||||
|
|
|
@ -210,7 +210,7 @@ are always available. They are listed here in alphabetical order.
|
|||
The optional arguments *flags* and *dont_inherit* control which future
|
||||
statements (see :pep:`236`) affect the compilation of *source*. If neither
|
||||
is present (or both are zero) the code is compiled with those future
|
||||
statements that are in effect in the code that is calling compile. If the
|
||||
statements that are in effect in the code that is calling :func:`compile`. If the
|
||||
*flags* argument is given and *dont_inherit* is not (or is zero) then the
|
||||
future statements specified by the *flags* argument are used in addition to
|
||||
those that would be used anyway. If *dont_inherit* is a non-zero integer then
|
||||
|
@ -231,6 +231,9 @@ are always available. They are listed here in alphabetical order.
|
|||
This function raises :exc:`SyntaxError` if the compiled source is invalid,
|
||||
and :exc:`TypeError` if the source contains null bytes.
|
||||
|
||||
If you want to parse Python code into its AST representation, see
|
||||
:func:`ast.parse`.
|
||||
|
||||
.. note::
|
||||
|
||||
When compiling a string with multi-line code in ``'single'`` or
|
||||
|
@ -539,7 +542,7 @@ are always available. They are listed here in alphabetical order.
|
|||
effect as calling :func:`str(value) <str>`.
|
||||
|
||||
A call to ``format(value, format_spec)`` is translated to
|
||||
``type(value).__format__(format_spec)`` which bypasses the instance
|
||||
``type(value).__format__(value, format_spec)`` which bypasses the instance
|
||||
dictionary when searching for the value's :meth:`__format__` method. A
|
||||
:exc:`TypeError` exception is raised if the method search reaches
|
||||
:mod:`object` and the *format_spec* is non-empty, or if either the
|
||||
|
|
|
@ -269,8 +269,8 @@ the same rule. [2]_ The constructors :func:`int`, :func:`float`, and
|
|||
:func:`complex` can be used to produce numbers of a specific type.
|
||||
|
||||
All numeric types (except complex) support the following operations, sorted by
|
||||
ascending priority (operations in the same box have the same priority; all
|
||||
numeric operations have a higher priority than comparison operations):
|
||||
ascending priority (all numeric operations have a higher priority than
|
||||
comparison operations):
|
||||
|
||||
+---------------------+---------------------------------+---------+--------------------+
|
||||
| Operation | Result | Notes | Full documentation |
|
||||
|
@ -404,8 +404,7 @@ The priorities of the binary bitwise operations are all lower than the numeric
|
|||
operations and higher than the comparisons; the unary operation ``~`` has the
|
||||
same priority as the other unary numeric operations (``+`` and ``-``).
|
||||
|
||||
This table lists the bitwise operations sorted in ascending priority
|
||||
(operations in the same box have the same priority):
|
||||
This table lists the bitwise operations sorted in ascending priority:
|
||||
|
||||
+------------+--------------------------------+----------+
|
||||
| Operation | Result | Notes |
|
||||
|
@ -444,7 +443,7 @@ Additional Methods on Integer Types
|
|||
-----------------------------------
|
||||
|
||||
The int type implements the :class:`numbers.Integral` :term:`abstract base
|
||||
class`. In addition, it provides one more method:
|
||||
class`. In addition, it provides a few more methods:
|
||||
|
||||
.. method:: int.bit_length()
|
||||
|
||||
|
@ -820,10 +819,10 @@ both mutable and immutable. The :class:`collections.abc.Sequence` ABC is
|
|||
provided to make it easier to correctly implement these operations on
|
||||
custom sequence types.
|
||||
|
||||
This table lists the sequence operations sorted in ascending priority
|
||||
(operations in the same box have the same priority). In the table, *s* and *t*
|
||||
are sequences of the same type, *n*, *i*, *j* and *k* are integers and *x* is
|
||||
an arbitrary object that meets any type and value restrictions imposed by *s*.
|
||||
This table lists the sequence operations sorted in ascending priority. In the
|
||||
table, *s* and *t* are sequences of the same type, *n*, *i*, *j* and *k* are
|
||||
integers and *x* is an arbitrary object that meets any type and value
|
||||
restrictions imposed by *s*.
|
||||
|
||||
The ``in`` and ``not in`` operations have the same priorities as the
|
||||
comparison operations. The ``+`` (concatenation) and ``*`` (repetition)
|
||||
|
@ -4006,8 +4005,8 @@ before the statement body is executed and exited when the statement ends:
|
|||
The exception passed in should never be reraised explicitly - instead, this
|
||||
method should return a false value to indicate that the method completed
|
||||
successfully and does not want to suppress the raised exception. This allows
|
||||
context management code (such as ``contextlib.nested``) to easily detect whether
|
||||
or not an :meth:`__exit__` method has actually failed.
|
||||
context management code to easily detect whether or not an :meth:`__exit__`
|
||||
method has actually failed.
|
||||
|
||||
Python defines several context managers to support easy thread synchronisation,
|
||||
prompt closure of files or other objects, and simpler manipulation of the active
|
||||
|
|
Loading…
Reference in New Issue