mirror of
https://github.com/python/cpython.git
synced 2025-12-08 06:10:17 +00:00
Python 3.14.1
This commit is contained in:
Hugo van Kemenade
parent
49fe7574d9
commit
57e0d177c2
209 changed files with 2451 additions and 548 deletions
|
|
@ -1,4 +1,4 @@
|
|||
# Autogenerated by Sphinx on Tue Oct 7 12:34:44 2025
|
||||
# Autogenerated by Sphinx on Tue Dec 2 14:51:32 2025
|
||||
# as part of the release process.
|
||||
|
||||
topics = {
|
||||
|
|
@ -1098,10 +1098,10 @@ class and instance attributes applies as for regular assignments.
|
|||
'bltin-ellipsis-object': r'''The Ellipsis Object
|
||||
*******************
|
||||
|
||||
This object is commonly used used to indicate that something is
|
||||
omitted. It supports no special operations. There is exactly one
|
||||
ellipsis object, named "Ellipsis" (a built-in name).
|
||||
"type(Ellipsis)()" produces the "Ellipsis" singleton.
|
||||
This object is commonly used to indicate that something is omitted. It
|
||||
supports no special operations. There is exactly one ellipsis object,
|
||||
named "Ellipsis" (a built-in name). "type(Ellipsis)()" produces the
|
||||
"Ellipsis" singleton.
|
||||
|
||||
It is written as "Ellipsis" or "...".
|
||||
|
||||
|
|
@ -1946,15 +1946,29 @@ class attributes; they are shared by instances. Instance attributes
|
|||
"except*" clause
|
||||
----------------
|
||||
|
||||
The "except*" clause(s) are used for handling "ExceptionGroup"s. The
|
||||
exception type for matching is interpreted as in the case of "except",
|
||||
but in the case of exception groups we can have partial matches when
|
||||
the type matches some of the exceptions in the group. This means that
|
||||
multiple "except*" clauses can execute, each handling part of the
|
||||
exception group. Each clause executes at most once and handles an
|
||||
exception group of all matching exceptions. Each exception in the
|
||||
group is handled by at most one "except*" clause, the first that
|
||||
matches it.
|
||||
The "except*" clause(s) specify one or more handlers for groups of
|
||||
exceptions ("BaseExceptionGroup" instances). A "try" statement can
|
||||
have either "except" or "except*" clauses, but not both. The exception
|
||||
type for matching is mandatory in the case of "except*", so "except*:"
|
||||
is a syntax error. The type is interpreted as in the case of "except",
|
||||
but matching is performed on the exceptions contained in the group
|
||||
that is being handled. An "TypeError" is raised if a matching type is
|
||||
a subclass of "BaseExceptionGroup", because that would have ambiguous
|
||||
semantics.
|
||||
|
||||
When an exception group is raised in the try block, each "except*"
|
||||
clause splits (see "split()") it into the subgroups of matching and
|
||||
non-matching exceptions. If the matching subgroup is not empty, it
|
||||
becomes the handled exception (the value returned from
|
||||
"sys.exception()") and assigned to the target of the "except*" clause
|
||||
(if there is one). Then, the body of the "except*" clause executes. If
|
||||
the non-matching subgroup is not empty, it is processed by the next
|
||||
"except*" in the same manner. This continues until all exceptions in
|
||||
the group have been matched, or the last "except*" clause has run.
|
||||
|
||||
After all "except*" clauses execute, the group of unhandled exceptions
|
||||
is merged with any exceptions that were raised or re-raised from
|
||||
within "except*" clauses. This merged exception group propagates on.:
|
||||
|
||||
>>> try:
|
||||
... raise ExceptionGroup("eg",
|
||||
|
|
@ -1967,20 +1981,19 @@ class attributes; they are shared by instances. Instance attributes
|
|||
caught <class 'ExceptionGroup'> with nested (TypeError(2),)
|
||||
caught <class 'ExceptionGroup'> with nested (OSError(3), OSError(4))
|
||||
+ Exception Group Traceback (most recent call last):
|
||||
| File "<stdin>", line 2, in <module>
|
||||
| ExceptionGroup: eg
|
||||
| File "<doctest default[0]>", line 2, in <module>
|
||||
| raise ExceptionGroup("eg",
|
||||
| [ValueError(1), TypeError(2), OSError(3), OSError(4)])
|
||||
| ExceptionGroup: eg (1 sub-exception)
|
||||
+-+---------------- 1 ----------------
|
||||
| ValueError: 1
|
||||
+------------------------------------
|
||||
|
||||
Any remaining exceptions that were not handled by any "except*" clause
|
||||
are re-raised at the end, along with all exceptions that were raised
|
||||
from within the "except*" clauses. If this list contains more than one
|
||||
exception to reraise, they are combined into an exception group.
|
||||
|
||||
If the raised exception is not an exception group and its type matches
|
||||
one of the "except*" clauses, it is caught and wrapped by an exception
|
||||
group with an empty message string.
|
||||
If the exception raised from the "try" block is not an exception group
|
||||
and its type matches one of the "except*" clauses, it is caught and
|
||||
wrapped by an exception group with an empty message string. This
|
||||
ensures that the type of the target "e" is consistently
|
||||
"BaseExceptionGroup":
|
||||
|
||||
>>> try:
|
||||
... raise BlockingIOError
|
||||
|
|
@ -1989,13 +2002,7 @@ class attributes; they are shared by instances. Instance attributes
|
|||
...
|
||||
ExceptionGroup('', (BlockingIOError()))
|
||||
|
||||
An "except*" clause must have a matching expression; it cannot be
|
||||
"except*:". Furthermore, this expression cannot contain exception
|
||||
group types, because that would have ambiguous semantics.
|
||||
|
||||
It is not possible to mix "except" and "except*" in the same "try".
|
||||
The "break", "continue", and "return" statements cannot appear in an
|
||||
"except*" clause.
|
||||
"break", "continue" and "return" cannot appear in an "except*" clause.
|
||||
|
||||
|
||||
"else" clause
|
||||
|
|
@ -2665,7 +2672,7 @@ def foo():
|
|||
If only keyword patterns are present, they are processed as
|
||||
follows, one by one:
|
||||
|
||||
I. The keyword is looked up as an attribute on the subject.
|
||||
1. The keyword is looked up as an attribute on the subject.
|
||||
|
||||
* If this raises an exception other than "AttributeError", the
|
||||
exception bubbles up.
|
||||
|
|
@ -2677,14 +2684,14 @@ def foo():
|
|||
the class pattern fails; if this succeeds, the match proceeds
|
||||
to the next keyword.
|
||||
|
||||
II. If all keyword patterns succeed, the class pattern succeeds.
|
||||
2. If all keyword patterns succeed, the class pattern succeeds.
|
||||
|
||||
If any positional patterns are present, they are converted to
|
||||
keyword patterns using the "__match_args__" attribute on the class
|
||||
"name_or_attr" before matching:
|
||||
|
||||
I. The equivalent of "getattr(cls, "__match_args__", ())" is
|
||||
called.
|
||||
1. The equivalent of "getattr(cls, "__match_args__", ())" is
|
||||
called.
|
||||
|
||||
* If this raises an exception, the exception bubbles up.
|
||||
|
||||
|
|
@ -2705,9 +2712,9 @@ def foo():
|
|||
|
||||
Customizing positional arguments in class pattern matching
|
||||
|
||||
II. Once all positional patterns have been converted to keyword
|
||||
patterns,
|
||||
the match proceeds as if there were only keyword patterns.
|
||||
2. Once all positional patterns have been converted to keyword
|
||||
patterns, the match proceeds as if there were only keyword
|
||||
patterns.
|
||||
|
||||
For the following built-in types the handling of positional
|
||||
subpatterns is different:
|
||||
|
|
@ -3909,6 +3916,10 @@ def double(x):
|
|||
available for commands and command arguments, e.g. the current global
|
||||
and local names are offered as arguments of the "p" command.
|
||||
|
||||
|
||||
Command-line interface
|
||||
======================
|
||||
|
||||
You can also invoke "pdb" from the command line to debug other
|
||||
scripts. For example:
|
||||
|
||||
|
|
@ -3924,7 +3935,7 @@ def double(x):
|
|||
-c, --command <command>
|
||||
|
||||
To execute commands as if given in a ".pdbrc" file; see Debugger
|
||||
Commands.
|
||||
commands.
|
||||
|
||||
Changed in version 3.2: Added the "-c" option.
|
||||
|
||||
|
|
@ -4145,7 +4156,7 @@ class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=Fa
|
|||
See the documentation for the functions explained above.
|
||||
|
||||
|
||||
Debugger Commands
|
||||
Debugger commands
|
||||
=================
|
||||
|
||||
The commands recognized by the debugger are listed below. Most
|
||||
|
|
@ -4808,11 +4819,6 @@ class of the instance or a *non-virtual base class* thereof. The
|
|||
|
||||
See also the description of the "try" statement in section The try
|
||||
statement and "raise" statement in section The raise statement.
|
||||
|
||||
-[ Footnotes ]-
|
||||
|
||||
[1] This limitation occurs because the code that is executed by these
|
||||
operations is not available at the time the module is compiled.
|
||||
''',
|
||||
'execmodel': r'''Execution model
|
||||
***************
|
||||
|
|
@ -5166,6 +5172,181 @@ class of the instance or a *non-virtual base class* thereof. The
|
|||
See also the description of the "try" statement in section The try
|
||||
statement and "raise" statement in section The raise statement.
|
||||
|
||||
|
||||
Runtime Components
|
||||
==================
|
||||
|
||||
|
||||
General Computing Model
|
||||
-----------------------
|
||||
|
||||
Python’s execution model does not operate in a vacuum. It runs on a
|
||||
host machine and through that host’s runtime environment, including
|
||||
its operating system (OS), if there is one. When a program runs, the
|
||||
conceptual layers of how it runs on the host look something like this:
|
||||
|
||||
**host machine**
|
||||
**process** (global resources)
|
||||
**thread** (runs machine code)
|
||||
|
||||
Each process represents a program running on the host. Think of each
|
||||
process itself as the data part of its program. Think of the process’
|
||||
threads as the execution part of the program. This distinction will
|
||||
be important to understand the conceptual Python runtime.
|
||||
|
||||
The process, as the data part, is the execution context in which the
|
||||
program runs. It mostly consists of the set of resources assigned to
|
||||
the program by the host, including memory, signals, file handles,
|
||||
sockets, and environment variables.
|
||||
|
||||
Processes are isolated and independent from one another. (The same is
|
||||
true for hosts.) The host manages the process’ access to its assigned
|
||||
resources, in addition to coordinating between processes.
|
||||
|
||||
Each thread represents the actual execution of the program’s machine
|
||||
code, running relative to the resources assigned to the program’s
|
||||
process. It’s strictly up to the host how and when that execution
|
||||
takes place.
|
||||
|
||||
From the point of view of Python, a program always starts with exactly
|
||||
one thread. However, the program may grow to run in multiple
|
||||
simultaneous threads. Not all hosts support multiple threads per
|
||||
process, but most do. Unlike processes, threads in a process are not
|
||||
isolated and independent from one another. Specifically, all threads
|
||||
in a process share all of the process’ resources.
|
||||
|
||||
The fundamental point of threads is that each one does *run*
|
||||
independently, at the same time as the others. That may be only
|
||||
conceptually at the same time (“concurrently”) or physically (“in
|
||||
parallel”). Either way, the threads effectively run at a non-
|
||||
synchronized rate.
|
||||
|
||||
Note:
|
||||
|
||||
That non-synchronized rate means none of the process’ memory is
|
||||
guaranteed to stay consistent for the code running in any given
|
||||
thread. Thus multi-threaded programs must take care to coordinate
|
||||
access to intentionally shared resources. Likewise, they must take
|
||||
care to be absolutely diligent about not accessing any *other*
|
||||
resources in multiple threads; otherwise two threads running at the
|
||||
same time might accidentally interfere with each other’s use of some
|
||||
shared data. All this is true for both Python programs and the
|
||||
Python runtime.The cost of this broad, unstructured requirement is
|
||||
the tradeoff for the kind of raw concurrency that threads provide.
|
||||
The alternative to the required discipline generally means dealing
|
||||
with non-deterministic bugs and data corruption.
|
||||
|
||||
|
||||
Python Runtime Model
|
||||
--------------------
|
||||
|
||||
The same conceptual layers apply to each Python program, with some
|
||||
extra data layers specific to Python:
|
||||
|
||||
**host machine**
|
||||
**process** (global resources)
|
||||
Python global runtime (*state*)
|
||||
Python interpreter (*state*)
|
||||
**thread** (runs Python bytecode and “C-API”)
|
||||
Python thread *state*
|
||||
|
||||
At the conceptual level: when a Python program starts, it looks
|
||||
exactly like that diagram, with one of each. The runtime may grow to
|
||||
include multiple interpreters, and each interpreter may grow to
|
||||
include multiple thread states.
|
||||
|
||||
Note:
|
||||
|
||||
A Python implementation won’t necessarily implement the runtime
|
||||
layers distinctly or even concretely. The only exception is places
|
||||
where distinct layers are directly specified or exposed to users,
|
||||
like through the "threading" module.
|
||||
|
||||
Note:
|
||||
|
||||
The initial interpreter is typically called the “main” interpreter.
|
||||
Some Python implementations, like CPython, assign special roles to
|
||||
the main interpreter.Likewise, the host thread where the runtime was
|
||||
initialized is known as the “main” thread. It may be different from
|
||||
the process’ initial thread, though they are often the same. In
|
||||
some cases “main thread” may be even more specific and refer to the
|
||||
initial thread state. A Python runtime might assign specific
|
||||
responsibilities to the main thread, such as handling signals.
|
||||
|
||||
As a whole, the Python runtime consists of the global runtime state,
|
||||
interpreters, and thread states. The runtime ensures all that state
|
||||
stays consistent over its lifetime, particularly when used with
|
||||
multiple host threads.
|
||||
|
||||
The global runtime, at the conceptual level, is just a set of
|
||||
interpreters. While those interpreters are otherwise isolated and
|
||||
independent from one another, they may share some data or other
|
||||
resources. The runtime is responsible for managing these global
|
||||
resources safely. The actual nature and management of these resources
|
||||
is implementation-specific. Ultimately, the external utility of the
|
||||
global runtime is limited to managing interpreters.
|
||||
|
||||
In contrast, an “interpreter” is conceptually what we would normally
|
||||
think of as the (full-featured) “Python runtime”. When machine code
|
||||
executing in a host thread interacts with the Python runtime, it calls
|
||||
into Python in the context of a specific interpreter.
|
||||
|
||||
Note:
|
||||
|
||||
The term “interpreter” here is not the same as the “bytecode
|
||||
interpreter”, which is what regularly runs in threads, executing
|
||||
compiled Python code.In an ideal world, “Python runtime” would refer
|
||||
to what we currently call “interpreter”. However, it’s been called
|
||||
“interpreter” at least since introduced in 1997 (CPython:a027efa5b).
|
||||
|
||||
Each interpreter completely encapsulates all of the non-process-
|
||||
global, non-thread-specific state needed for the Python runtime to
|
||||
work. Notably, the interpreter’s state persists between uses. It
|
||||
includes fundamental data like "sys.modules". The runtime ensures
|
||||
multiple threads using the same interpreter will safely share it
|
||||
between them.
|
||||
|
||||
A Python implementation may support using multiple interpreters at the
|
||||
same time in the same process. They are independent and isolated from
|
||||
one another. For example, each interpreter has its own "sys.modules".
|
||||
|
||||
For thread-specific runtime state, each interpreter has a set of
|
||||
thread states, which it manages, in the same way the global runtime
|
||||
contains a set of interpreters. It can have thread states for as many
|
||||
host threads as it needs. It may even have multiple thread states for
|
||||
the same host thread, though that isn’t as common.
|
||||
|
||||
Each thread state, conceptually, has all the thread-specific runtime
|
||||
data an interpreter needs to operate in one host thread. The thread
|
||||
state includes the current raised exception and the thread’s Python
|
||||
call stack. It may include other thread-specific resources.
|
||||
|
||||
Note:
|
||||
|
||||
The term “Python thread” can sometimes refer to a thread state, but
|
||||
normally it means a thread created using the "threading" module.
|
||||
|
||||
Each thread state, over its lifetime, is always tied to exactly one
|
||||
interpreter and exactly one host thread. It will only ever be used in
|
||||
that thread and with that interpreter.
|
||||
|
||||
Multiple thread states may be tied to the same host thread, whether
|
||||
for different interpreters or even the same interpreter. However, for
|
||||
any given host thread, only one of the thread states tied to it can be
|
||||
used by the thread at a time.
|
||||
|
||||
Thread states are isolated and independent from one another and don’t
|
||||
share any data, except for possibly sharing an interpreter and objects
|
||||
or other resources belonging to that interpreter.
|
||||
|
||||
Once a program is running, new Python threads can be created using the
|
||||
"threading" module (on platforms and Python implementations that
|
||||
support threads). Additional processes can be created using the "os",
|
||||
"subprocess", and "multiprocessing" modules. Interpreters can be
|
||||
created and used with the "interpreters" module. Coroutines (async)
|
||||
can be run using "asyncio" in each interpreter, typically only in a
|
||||
single thread (often the main thread).
|
||||
|
||||
-[ Footnotes ]-
|
||||
|
||||
[1] This limitation occurs because the code that is executed by these
|
||||
|
|
@ -5215,9 +5396,8 @@ class of the instance or a *non-virtual base class* thereof. The
|
|||
2.71828
|
||||
4.0
|
||||
|
||||
Unlike in integer literals, leading zeros are allowed in the numeric
|
||||
parts. For example, "077.010" is legal, and denotes the same number as
|
||||
"77.10".
|
||||
Unlike in integer literals, leading zeros are allowed. For example,
|
||||
"077.010" is legal, and denotes the same number as "77.01".
|
||||
|
||||
As in integer literals, single underscores may occur between digits to
|
||||
help readability:
|
||||
|
|
@ -6012,9 +6192,15 @@ def whats_on_the_telly(penguin=None):
|
|||
without "global", although free variables may refer to globals without
|
||||
being declared global.
|
||||
|
||||
The "global" statement applies to the entire scope of a function or
|
||||
class body. A "SyntaxError" is raised if a variable is used or
|
||||
assigned to prior to its global declaration in the scope.
|
||||
The "global" statement applies to the entire current scope (module,
|
||||
function body or class definition). A "SyntaxError" is raised if a
|
||||
variable is used or assigned to prior to its global declaration in the
|
||||
scope.
|
||||
|
||||
At the module level, all variables are global, so a "global" statement
|
||||
has no effect. However, variables must still not be used or assigned
|
||||
to prior to their "global" declaration. This requirement is relaxed in
|
||||
the interactive prompt (*REPL*).
|
||||
|
||||
**Programmer’s note:** "global" is a directive to the parser. It
|
||||
applies only to code parsed at the same time as the "global"
|
||||
|
|
@ -7028,9 +7214,8 @@ class body. A "SyntaxError" is raised if a variable is used or
|
|||
2.71828
|
||||
4.0
|
||||
|
||||
Unlike in integer literals, leading zeros are allowed in the numeric
|
||||
parts. For example, "077.010" is legal, and denotes the same number as
|
||||
"77.10".
|
||||
Unlike in integer literals, leading zeros are allowed. For example,
|
||||
"077.010" is legal, and denotes the same number as "77.01".
|
||||
|
||||
As in integer literals, single underscores may occur between digits to
|
||||
help readability:
|
||||
|
|
@ -7278,9 +7463,8 @@ class that has an "__rsub__()" method, "type(y).__rsub__(y, x)" is
|
|||
*************************
|
||||
|
||||
*Objects* are Python’s abstraction for data. All data in a Python
|
||||
program is represented by objects or by relations between objects. (In
|
||||
a sense, and in conformance to Von Neumann’s model of a “stored
|
||||
program computer”, code is also represented by objects.)
|
||||
program is represented by objects or by relations between objects.
|
||||
Even code is represented by objects.
|
||||
|
||||
Every object has an identity, a type and a value. An object’s
|
||||
*identity* never changes once it has been created; you may think of it
|
||||
|
|
@ -9742,10 +9926,14 @@ class is used in a class pattern with positional arguments, each
|
|||
the numeric index of a positional argument, or the name of a
|
||||
keyword argument. Returns a copy of the string where each
|
||||
replacement field is replaced with the string value of the
|
||||
corresponding argument.
|
||||
corresponding argument. For example:
|
||||
|
||||
>>> "The sum of 1 + 2 is {0}".format(1+2)
|
||||
'The sum of 1 + 2 is 3'
|
||||
>>> "The sum of 1 + 2 is {0}".format(1+2)
|
||||
'The sum of 1 + 2 is 3'
|
||||
>>> "The sum of {a} + {b} is {answer}".format(answer=1+2, a=1, b=2)
|
||||
'The sum of 1 + 2 is 3'
|
||||
>>> "{1} expects the {0} Inquisition!".format("Spanish", "Nobody")
|
||||
'Nobody expects the Spanish Inquisition!'
|
||||
|
||||
See Format String Syntax for a description of the various
|
||||
formatting options that can be specified in format strings.
|
||||
|
|
@ -9800,13 +9988,28 @@ class is used in a class pattern with positional arguments, each
|
|||
database as “Letter”, i.e., those with general category property
|
||||
being one of “Lm”, “Lt”, “Lu”, “Ll”, or “Lo”. Note that this is
|
||||
different from the Alphabetic property defined in the section 4.10
|
||||
‘Letters, Alphabetic, and Ideographic’ of the Unicode Standard.
|
||||
‘Letters, Alphabetic, and Ideographic’ of the Unicode Standard. For
|
||||
example:
|
||||
|
||||
>>> 'Letters and spaces'.isalpha()
|
||||
False
|
||||
>>> 'LettersOnly'.isalpha()
|
||||
True
|
||||
>>> 'µ'.isalpha() # non-ASCII characters can be considered alphabetical too
|
||||
True
|
||||
|
||||
See Unicode Properties.
|
||||
|
||||
str.isascii()
|
||||
|
||||
Return "True" if the string is empty or all characters in the
|
||||
string are ASCII, "False" otherwise. ASCII characters have code
|
||||
points in the range U+0000-U+007F.
|
||||
points in the range U+0000-U+007F. For example:
|
||||
|
||||
>>> 'ASCII characters'.isascii()
|
||||
True
|
||||
>>> 'µ'.isascii()
|
||||
False
|
||||
|
||||
Added in version 3.7.
|
||||
|
||||
|
|
@ -9815,8 +10018,16 @@ class is used in a class pattern with positional arguments, each
|
|||
Return "True" if all characters in the string are decimal
|
||||
characters and there is at least one character, "False" otherwise.
|
||||
Decimal characters are those that can be used to form numbers in
|
||||
base 10, e.g. U+0660, ARABIC-INDIC DIGIT ZERO. Formally a decimal
|
||||
character is a character in the Unicode General Category “Nd”.
|
||||
base 10, such as U+0660, ARABIC-INDIC DIGIT ZERO. Formally a
|
||||
decimal character is a character in the Unicode General Category
|
||||
“Nd”. For example:
|
||||
|
||||
>>> '0123456789'.isdecimal()
|
||||
True
|
||||
>>> '٠١٢٣٤٥٦٧٨٩'.isdecimal() # Arabic-Indic digits zero to nine
|
||||
True
|
||||
>>> 'alphabetic'.isdecimal()
|
||||
False
|
||||
|
||||
str.isdigit()
|
||||
|
||||
|
|
@ -9894,6 +10105,17 @@ class is used in a class pattern with positional arguments, each
|
|||
follow uncased characters and lowercase characters only cased ones.
|
||||
Return "False" otherwise.
|
||||
|
||||
For example:
|
||||
|
||||
>>> 'Spam, Spam, Spam'.istitle()
|
||||
True
|
||||
>>> 'spam, spam, spam'.istitle()
|
||||
False
|
||||
>>> 'SPAM, SPAM, SPAM'.istitle()
|
||||
False
|
||||
|
||||
See also "title()".
|
||||
|
||||
str.isupper()
|
||||
|
||||
Return "True" if all cased characters [4] in the string are
|
||||
|
|
@ -9914,7 +10136,15 @@ class is used in a class pattern with positional arguments, each
|
|||
Return a string which is the concatenation of the strings in
|
||||
*iterable*. A "TypeError" will be raised if there are any non-
|
||||
string values in *iterable*, including "bytes" objects. The
|
||||
separator between elements is the string providing this method.
|
||||
separator between elements is the string providing this method. For
|
||||
example:
|
||||
|
||||
>>> ', '.join(['spam', 'spam', 'spam'])
|
||||
'spam, spam, spam'
|
||||
>>> '-'.join('Python')
|
||||
'P-y-t-h-o-n'
|
||||
|
||||
See also "split()".
|
||||
|
||||
str.ljust(width, fillchar=' ', /)
|
||||
|
||||
|
|
@ -10124,6 +10354,8 @@ class is used in a class pattern with positional arguments, each
|
|||
>>> " foo ".split(maxsplit=0)
|
||||
['foo ']
|
||||
|
||||
See also "join()".
|
||||
|
||||
str.splitlines(keepends=False)
|
||||
|
||||
Return a list of the lines in the string, breaking at line
|
||||
|
|
@ -10256,6 +10488,8 @@ class is used in a class pattern with positional arguments, each
|
|||
>>> titlecase("they're bill's friends.")
|
||||
"They're Bill's Friends."
|
||||
|
||||
See also "istitle()".
|
||||
|
||||
str.translate(table, /)
|
||||
|
||||
Return a copy of the string in which each character has been mapped
|
||||
|
|
@ -11005,15 +11239,29 @@ class is used in a class pattern with positional arguments, each
|
|||
"except*" clause
|
||||
================
|
||||
|
||||
The "except*" clause(s) are used for handling "ExceptionGroup"s. The
|
||||
exception type for matching is interpreted as in the case of "except",
|
||||
but in the case of exception groups we can have partial matches when
|
||||
the type matches some of the exceptions in the group. This means that
|
||||
multiple "except*" clauses can execute, each handling part of the
|
||||
exception group. Each clause executes at most once and handles an
|
||||
exception group of all matching exceptions. Each exception in the
|
||||
group is handled by at most one "except*" clause, the first that
|
||||
matches it.
|
||||
The "except*" clause(s) specify one or more handlers for groups of
|
||||
exceptions ("BaseExceptionGroup" instances). A "try" statement can
|
||||
have either "except" or "except*" clauses, but not both. The exception
|
||||
type for matching is mandatory in the case of "except*", so "except*:"
|
||||
is a syntax error. The type is interpreted as in the case of "except",
|
||||
but matching is performed on the exceptions contained in the group
|
||||
that is being handled. An "TypeError" is raised if a matching type is
|
||||
a subclass of "BaseExceptionGroup", because that would have ambiguous
|
||||
semantics.
|
||||
|
||||
When an exception group is raised in the try block, each "except*"
|
||||
clause splits (see "split()") it into the subgroups of matching and
|
||||
non-matching exceptions. If the matching subgroup is not empty, it
|
||||
becomes the handled exception (the value returned from
|
||||
"sys.exception()") and assigned to the target of the "except*" clause
|
||||
(if there is one). Then, the body of the "except*" clause executes. If
|
||||
the non-matching subgroup is not empty, it is processed by the next
|
||||
"except*" in the same manner. This continues until all exceptions in
|
||||
the group have been matched, or the last "except*" clause has run.
|
||||
|
||||
After all "except*" clauses execute, the group of unhandled exceptions
|
||||
is merged with any exceptions that were raised or re-raised from
|
||||
within "except*" clauses. This merged exception group propagates on.:
|
||||
|
||||
>>> try:
|
||||
... raise ExceptionGroup("eg",
|
||||
|
|
@ -11026,20 +11274,19 @@ class is used in a class pattern with positional arguments, each
|
|||
caught <class 'ExceptionGroup'> with nested (TypeError(2),)
|
||||
caught <class 'ExceptionGroup'> with nested (OSError(3), OSError(4))
|
||||
+ Exception Group Traceback (most recent call last):
|
||||
| File "<stdin>", line 2, in <module>
|
||||
| ExceptionGroup: eg
|
||||
| File "<doctest default[0]>", line 2, in <module>
|
||||
| raise ExceptionGroup("eg",
|
||||
| [ValueError(1), TypeError(2), OSError(3), OSError(4)])
|
||||
| ExceptionGroup: eg (1 sub-exception)
|
||||
+-+---------------- 1 ----------------
|
||||
| ValueError: 1
|
||||
+------------------------------------
|
||||
|
||||
Any remaining exceptions that were not handled by any "except*" clause
|
||||
are re-raised at the end, along with all exceptions that were raised
|
||||
from within the "except*" clauses. If this list contains more than one
|
||||
exception to reraise, they are combined into an exception group.
|
||||
|
||||
If the raised exception is not an exception group and its type matches
|
||||
one of the "except*" clauses, it is caught and wrapped by an exception
|
||||
group with an empty message string.
|
||||
If the exception raised from the "try" block is not an exception group
|
||||
and its type matches one of the "except*" clauses, it is caught and
|
||||
wrapped by an exception group with an empty message string. This
|
||||
ensures that the type of the target "e" is consistently
|
||||
"BaseExceptionGroup":
|
||||
|
||||
>>> try:
|
||||
... raise BlockingIOError
|
||||
|
|
@ -11048,13 +11295,7 @@ class is used in a class pattern with positional arguments, each
|
|||
...
|
||||
ExceptionGroup('', (BlockingIOError()))
|
||||
|
||||
An "except*" clause must have a matching expression; it cannot be
|
||||
"except*:". Furthermore, this expression cannot contain exception
|
||||
group types, because that would have ambiguous semantics.
|
||||
|
||||
It is not possible to mix "except" and "except*" in the same "try".
|
||||
The "break", "continue", and "return" statements cannot appear in an
|
||||
"except*" clause.
|
||||
"break", "continue" and "return" cannot appear in an "except*" clause.
|
||||
|
||||
|
||||
"else" clause
|
||||
|
|
@ -11949,6 +12190,11 @@ class method object, it is transformed into an instance method object
|
|||
| | "X.__bases__" will be exactly equal to "(A, B, |
|
||||
| | C)". |
|
||||
+----------------------------------------------------+----------------------------------------------------+
|
||||
| type.__base__ | **CPython implementation detail:** The single base |
|
||||
| | class in the inheritance chain that is responsible |
|
||||
| | for the memory layout of instances. This attribute |
|
||||
| | corresponds to "tp_base" at the C level. |
|
||||
+----------------------------------------------------+----------------------------------------------------+
|
||||
| type.__doc__ | The class’s documentation string, or "None" if |
|
||||
| | undefined. Not inherited by subclasses. |
|
||||
+----------------------------------------------------+----------------------------------------------------+
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue