mirror of
https://github.com/python/cpython.git
synced 2025-08-04 00:48:58 +00:00
Python 3.14.0b2
This commit is contained in:
Hugo van Kemenade
parent
6c917cb11c
commit
12d3f883ae
78 changed files with 958 additions and 276 deletions
|
|
@ -1,4 +1,4 @@
|
|||
# Autogenerated by Sphinx on Tue May 6 18:33:44 2025
|
||||
# Autogenerated by Sphinx on Mon May 26 16:26:41 2025
|
||||
# as part of the release process.
|
||||
|
||||
topics = {
|
||||
|
|
@ -435,9 +435,9 @@ See also:
|
|||
'atom-identifiers': r'''Identifiers (Names)
|
||||
*******************
|
||||
|
||||
An identifier occurring as an atom is a name. See section Identifiers
|
||||
and keywords for lexical definition and section Naming and binding for
|
||||
documentation of naming and binding.
|
||||
An identifier occurring as an atom is a name. See section Names
|
||||
(identifiers and keywords) for lexical definition and section Naming
|
||||
and binding for documentation of naming and binding.
|
||||
|
||||
When the name is bound to an object, evaluation of the atom yields
|
||||
that object. When a name is not bound, an attempt to evaluate it
|
||||
|
|
@ -1724,16 +1724,16 @@ The "for" statement
|
|||
The "for" statement is used to iterate over the elements of a sequence
|
||||
(such as a string, tuple or list) or other iterable object:
|
||||
|
||||
for_stmt: "for" target_list "in" starred_list ":" suite
|
||||
for_stmt: "for" target_list "in" starred_expression_list ":" suite
|
||||
["else" ":" suite]
|
||||
|
||||
The "starred_list" expression is evaluated once; it should yield an
|
||||
*iterable* object. An *iterator* is created for that iterable. The
|
||||
first item provided by the iterator is then assigned to the target
|
||||
list using the standard rules for assignments (see Assignment
|
||||
statements), and the suite is executed. This repeats for each item
|
||||
provided by the iterator. When the iterator is exhausted, the suite
|
||||
in the "else" clause, if present, is executed, and the loop
|
||||
The "starred_expression_list" expression is evaluated once; it should
|
||||
yield an *iterable* object. An *iterator* is created for that
|
||||
iterable. The first item provided by the iterator is then assigned to
|
||||
the target list using the standard rules for assignments (see
|
||||
Assignment statements), and the suite is executed. This repeats for
|
||||
each item provided by the iterator. When the iterator is exhausted,
|
||||
the suite in the "else" clause, if present, is executed, and the loop
|
||||
terminates.
|
||||
|
||||
A "break" statement executed in the first suite terminates the loop
|
||||
|
|
@ -3304,7 +3304,7 @@ runtime semantics of the code, except if some mechanism is used that
|
|||
introspects and uses the annotations (such as "dataclasses" or
|
||||
"functools.singledispatch()").
|
||||
|
||||
By default, annotations are lazily evaluated in a annotation scope.
|
||||
By default, annotations are lazily evaluated in an annotation scope.
|
||||
This means that they are not evaluated when the code containing the
|
||||
annotation is evaluated. Instead, the interpreter saves information
|
||||
that can be used to evaluate the annotation later if requested. The
|
||||
|
|
@ -3318,6 +3318,12 @@ present, all annotations are instead stored as strings:
|
|||
>>> f.__annotations__
|
||||
{'param': 'annotation'}
|
||||
|
||||
This future statement will be deprecated and removed in a future
|
||||
version of Python, but not before Python 3.13 reaches its end of life
|
||||
(see **PEP 749**). When it is used, introspection tools like
|
||||
"annotationlib.get_annotations()" and "typing.get_type_hints()" are
|
||||
less likely to be able to resolve annotations at runtime.
|
||||
|
||||
-[ Footnotes ]-
|
||||
|
||||
[1] The exception is propagated to the invocation stack unless there
|
||||
|
|
@ -3832,7 +3838,7 @@ and local names are offered as arguments of the "p" command.
|
|||
You can also invoke "pdb" from the command line to debug other
|
||||
scripts. For example:
|
||||
|
||||
python -m pdb [-c command] (-m module | pyfile) [args ...]
|
||||
python -m pdb [-c command] (-m module | -p pid | pyfile) [args ...]
|
||||
|
||||
When invoked as a module, pdb will automatically enter post-mortem
|
||||
debugging if the program being debugged exits abnormally. After post-
|
||||
|
|
@ -3856,6 +3862,23 @@ debugger upon program’s exit.
|
|||
|
||||
Changed in version 3.7: Added the "-m" option.
|
||||
|
||||
-p, --pid <pid>
|
||||
|
||||
Attach to the process with the specified PID.
|
||||
|
||||
Added in version 3.14.
|
||||
|
||||
To attach to a running Python process for remote debugging, use the
|
||||
"-p" or "--pid" option with the target process’s PID:
|
||||
|
||||
python -m pdb -p 1234
|
||||
|
||||
Note:
|
||||
|
||||
Attaching to a process that is blocked in a system call or waiting
|
||||
for I/O will only work once the next bytecode instruction is
|
||||
executed or when the process receives a signal.
|
||||
|
||||
Typical usage to execute a statement under control of the debugger is:
|
||||
|
||||
>>> import pdb
|
||||
|
|
@ -5077,7 +5100,7 @@ statement and "raise" statement in section The raise statement.
|
|||
'exprlists': r'''Expression lists
|
||||
****************
|
||||
|
||||
starred_expression: ["*"] or_expr
|
||||
starred_expression: "*" or_expr | expression
|
||||
flexible_expression: assignment_expression | starred_expression
|
||||
flexible_expression_list: flexible_expression ("," flexible_expression)* [","]
|
||||
starred_expression_list: starred_expression ("," starred_expression)* [","]
|
||||
|
|
@ -5138,16 +5161,16 @@ purposes in literals.
|
|||
The "for" statement is used to iterate over the elements of a sequence
|
||||
(such as a string, tuple or list) or other iterable object:
|
||||
|
||||
for_stmt: "for" target_list "in" starred_list ":" suite
|
||||
for_stmt: "for" target_list "in" starred_expression_list ":" suite
|
||||
["else" ":" suite]
|
||||
|
||||
The "starred_list" expression is evaluated once; it should yield an
|
||||
*iterable* object. An *iterator* is created for that iterable. The
|
||||
first item provided by the iterator is then assigned to the target
|
||||
list using the standard rules for assignments (see Assignment
|
||||
statements), and the suite is executed. This repeats for each item
|
||||
provided by the iterator. When the iterator is exhausted, the suite
|
||||
in the "else" clause, if present, is executed, and the loop
|
||||
The "starred_expression_list" expression is evaluated once; it should
|
||||
yield an *iterable* object. An *iterator* is created for that
|
||||
iterable. The first item provided by the iterator is then assigned to
|
||||
the target list using the standard rules for assignments (see
|
||||
Assignment statements), and the suite is executed. This repeats for
|
||||
each item provided by the iterator. When the iterator is exhausted,
|
||||
the suite in the "else" clause, if present, is executed, and the loop
|
||||
terminates.
|
||||
|
||||
A "break" statement executed in the first suite terminates the loop
|
||||
|
|
@ -5942,73 +5965,92 @@ trailing underscore characters:
|
|||
to help avoid name clashes between “private” attributes of base and
|
||||
derived classes. See section Identifiers (Names).
|
||||
''',
|
||||
'identifiers': r'''Identifiers and keywords
|
||||
************************
|
||||
'identifiers': r'''Names (identifiers and keywords)
|
||||
********************************
|
||||
|
||||
Identifiers (also referred to as *names*) are described by the
|
||||
following lexical definitions.
|
||||
|
||||
The syntax of identifiers in Python is based on the Unicode standard
|
||||
annex UAX-31, with elaboration and changes as defined below; see also
|
||||
**PEP 3131** for further details.
|
||||
"NAME" tokens represent *identifiers*, *keywords*, and *soft
|
||||
keywords*.
|
||||
|
||||
Within the ASCII range (U+0001..U+007F), the valid characters for
|
||||
identifiers include the uppercase and lowercase letters "A" through
|
||||
"Z", the underscore "_" and, except for the first character, the
|
||||
digits "0" through "9". Python 3.0 introduced additional characters
|
||||
from outside the ASCII range (see **PEP 3131**). For these
|
||||
characters, the classification uses the version of the Unicode
|
||||
Character Database as included in the "unicodedata" module.
|
||||
names include the uppercase and lowercase letters ("A-Z" and "a-z"),
|
||||
the underscore "_" and, except for the first character, the digits "0"
|
||||
through "9".
|
||||
|
||||
Identifiers are unlimited in length. Case is significant.
|
||||
Names must contain at least one character, but have no upper length
|
||||
limit. Case is significant.
|
||||
|
||||
identifier: xid_start xid_continue*
|
||||
id_start: <all characters in general categories Lu, Ll, Lt, Lm, Lo, Nl, the underscore, and characters with the Other_ID_Start property>
|
||||
id_continue: <all characters in id_start, plus characters in the categories Mn, Mc, Nd, Pc and others with the Other_ID_Continue property>
|
||||
xid_start: <all characters in id_start whose NFKC normalization is in "id_start xid_continue*">
|
||||
xid_continue: <all characters in id_continue whose NFKC normalization is in "id_continue*">
|
||||
Besides "A-Z", "a-z", "_" and "0-9", names can also use “letter-like”
|
||||
and “number-like” characters from outside the ASCII range, as detailed
|
||||
below.
|
||||
|
||||
The Unicode category codes mentioned above stand for:
|
||||
All identifiers are converted into the normalization form NFKC while
|
||||
parsing; comparison of identifiers is based on NFKC.
|
||||
|
||||
* *Lu* - uppercase letters
|
||||
Formally, the first character of a normalized identifier must belong
|
||||
to the set "id_start", which is the union of:
|
||||
|
||||
* *Ll* - lowercase letters
|
||||
* Unicode category "<Lu>" - uppercase letters (includes "A" to "Z")
|
||||
|
||||
* *Lt* - titlecase letters
|
||||
* Unicode category "<Ll>" - lowercase letters (includes "a" to "z")
|
||||
|
||||
* *Lm* - modifier letters
|
||||
* Unicode category "<Lt>" - titlecase letters
|
||||
|
||||
* *Lo* - other letters
|
||||
* Unicode category "<Lm>" - modifier letters
|
||||
|
||||
* *Nl* - letter numbers
|
||||
* Unicode category "<Lo>" - other letters
|
||||
|
||||
* *Mn* - nonspacing marks
|
||||
* Unicode category "<Nl>" - letter numbers
|
||||
|
||||
* *Mc* - spacing combining marks
|
||||
* {""_""} - the underscore
|
||||
|
||||
* *Nd* - decimal numbers
|
||||
* "<Other_ID_Start>" - an explicit set of characters in PropList.txt
|
||||
to support backwards compatibility
|
||||
|
||||
* *Pc* - connector punctuations
|
||||
The remaining characters must belong to the set "id_continue", which
|
||||
is the union of:
|
||||
|
||||
* *Other_ID_Start* - explicit list of characters in PropList.txt to
|
||||
support backwards compatibility
|
||||
* all characters in "id_start"
|
||||
|
||||
* *Other_ID_Continue* - likewise
|
||||
* Unicode category "<Nd>" - decimal numbers (includes "0" to "9")
|
||||
|
||||
All identifiers are converted into the normal form NFKC while parsing;
|
||||
comparison of identifiers is based on NFKC.
|
||||
* Unicode category "<Pc>" - connector punctuations
|
||||
|
||||
A non-normative HTML file listing all valid identifier characters for
|
||||
Unicode 16.0.0 can be found at
|
||||
https://www.unicode.org/Public/16.0.0/ucd/DerivedCoreProperties.txt
|
||||
* Unicode category "<Mn>" - nonspacing marks
|
||||
|
||||
* Unicode category "<Mc>" - spacing combining marks
|
||||
|
||||
* "<Other_ID_Continue>" - another explicit set of characters in
|
||||
PropList.txt to support backwards compatibility
|
||||
|
||||
Unicode categories use the version of the Unicode Character Database
|
||||
as included in the "unicodedata" module.
|
||||
|
||||
These sets are based on the Unicode standard annex UAX-31. See also
|
||||
**PEP 3131** for further details.
|
||||
|
||||
Even more formally, names are described by the following lexical
|
||||
definitions:
|
||||
|
||||
NAME: xid_start xid_continue*
|
||||
id_start: <Lu> | <Ll> | <Lt> | <Lm> | <Lo> | <Nl> | "_" | <Other_ID_Start>
|
||||
id_continue: id_start | <Nd> | <Pc> | <Mn> | <Mc> | <Other_ID_Continue>
|
||||
xid_start: <all characters in id_start whose NFKC normalization is
|
||||
in (id_start xid_continue*)">
|
||||
xid_continue: <all characters in id_continue whose NFKC normalization is
|
||||
in (id_continue*)">
|
||||
identifier: <NAME, except keywords>
|
||||
|
||||
A non-normative listing of all valid identifier characters as defined
|
||||
by Unicode is available in the DerivedCoreProperties.txt file in the
|
||||
Unicode Character Database.
|
||||
|
||||
|
||||
Keywords
|
||||
========
|
||||
|
||||
The following identifiers are used as reserved words, or *keywords* of
|
||||
the language, and cannot be used as ordinary identifiers. They must
|
||||
be spelled exactly as written here:
|
||||
The following names are used as reserved words, or *keywords* of the
|
||||
language, and cannot be used as ordinary identifiers. They must be
|
||||
spelled exactly as written here:
|
||||
|
||||
False await else import pass
|
||||
None break except in raise
|
||||
|
|
@ -6024,18 +6066,20 @@ Soft Keywords
|
|||
|
||||
Added in version 3.10.
|
||||
|
||||
Some identifiers are only reserved under specific contexts. These are
|
||||
known as *soft keywords*. The identifiers "match", "case", "type" and
|
||||
"_" can syntactically act as keywords in certain contexts, but this
|
||||
distinction is done at the parser level, not when tokenizing.
|
||||
Some names are only reserved under specific contexts. These are known
|
||||
as *soft keywords*:
|
||||
|
||||
* "match", "case", and "_", when used in the "match" statement.
|
||||
|
||||
* "type", when used in the "type" statement.
|
||||
|
||||
These syntactically act as keywords in their specific contexts, but
|
||||
this distinction is done at the parser level, not when tokenizing.
|
||||
|
||||
As soft keywords, their use in the grammar is possible while still
|
||||
preserving compatibility with existing code that uses these names as
|
||||
identifier names.
|
||||
|
||||
"match", "case", and "_" are used in the "match" statement. "type" is
|
||||
used in the "type" statement.
|
||||
|
||||
Changed in version 3.12: "type" is now a soft keyword.
|
||||
|
||||
|
||||
|
|
@ -6807,9 +6851,9 @@ object.__ror__(self, other)
|
|||
third argument if the three-argument version of the built-in
|
||||
"pow()" function is to be supported.
|
||||
|
||||
Changed in version 3.14.0a7 (unreleased): Three-argument "pow()"
|
||||
now try calling "__rpow__()" if necessary. Previously it was only
|
||||
called in two-argument "pow()" and the binary power operator.
|
||||
Changed in version 3.14: Three-argument "pow()" now try calling
|
||||
"__rpow__()" if necessary. Previously it was only called in two-
|
||||
argument "pow()" and the binary power operator.
|
||||
|
||||
Note:
|
||||
|
||||
|
|
@ -8845,9 +8889,9 @@ object.__ror__(self, other)
|
|||
third argument if the three-argument version of the built-in
|
||||
"pow()" function is to be supported.
|
||||
|
||||
Changed in version 3.14.0a7 (unreleased): Three-argument "pow()"
|
||||
now try calling "__rpow__()" if necessary. Previously it was only
|
||||
called in two-argument "pow()" and the binary power operator.
|
||||
Changed in version 3.14: Three-argument "pow()" now try calling
|
||||
"__rpow__()" if necessary. Previously it was only called in two-
|
||||
argument "pow()" and the binary power operator.
|
||||
|
||||
Note:
|
||||
|
||||
|
|
@ -9215,7 +9259,14 @@ str.center(width[, fillchar])
|
|||
Return centered in a string of length *width*. Padding is done
|
||||
using the specified *fillchar* (default is an ASCII space). The
|
||||
original string is returned if *width* is less than or equal to
|
||||
"len(s)".
|
||||
"len(s)". For example:
|
||||
|
||||
>>> 'Python'.center(10)
|
||||
' Python '
|
||||
>>> 'Python'.center(10, '-')
|
||||
'--Python--'
|
||||
>>> 'Python'.center(4)
|
||||
'Python'
|
||||
|
||||
str.count(sub[, start[, end]])
|
||||
|
||||
|
|
@ -9224,7 +9275,18 @@ str.count(sub[, start[, end]])
|
|||
*end* are interpreted as in slice notation.
|
||||
|
||||
If *sub* is empty, returns the number of empty strings between
|
||||
characters which is the length of the string plus one.
|
||||
characters which is the length of the string plus one. For example:
|
||||
|
||||
>>> 'spam, spam, spam'.count('spam')
|
||||
3
|
||||
>>> 'spam, spam, spam'.count('spam', 5)
|
||||
2
|
||||
>>> 'spam, spam, spam'.count('spam', 5, 10)
|
||||
1
|
||||
>>> 'spam, spam, spam'.count('eggs')
|
||||
0
|
||||
>>> 'spam, spam, spam'.count('')
|
||||
17
|
||||
|
||||
str.encode(encoding='utf-8', errors='strict')
|
||||
|
||||
|
|
@ -9389,7 +9451,7 @@ str.isdigit()
|
|||
str.isidentifier()
|
||||
|
||||
Return "True" if the string is a valid identifier according to the
|
||||
language definition, section Identifiers and keywords.
|
||||
language definition, section Names (identifiers and keywords).
|
||||
|
||||
"keyword.iskeyword()" can be used to test whether string "s" is a
|
||||
reserved identifier, such as "def" and "class".
|
||||
|
|
@ -9421,8 +9483,8 @@ str.isnumeric()
|
|||
|
||||
str.isprintable()
|
||||
|
||||
Return true if all characters in the string are printable, false if
|
||||
it contains at least one non-printable character.
|
||||
Return "True" if all characters in the string are printable,
|
||||
"False" if it contains at least one non-printable character.
|
||||
|
||||
Here “printable” means the character is suitable for "repr()" to
|
||||
use in its output; “non-printable” means that "repr()" on built-in
|
||||
|
|
@ -9669,6 +9731,18 @@ str.split(sep=None, maxsplit=-1)
|
|||
>>> ' 1 2 3 '.split()
|
||||
['1', '2', '3']
|
||||
|
||||
If *sep* is not specified or is "None" and *maxsplit* is "0", only
|
||||
leading runs of consecutive whitespace are considered.
|
||||
|
||||
For example:
|
||||
|
||||
>>> "".split(None, 0)
|
||||
[]
|
||||
>>> " ".split(None, 0)
|
||||
[]
|
||||
>>> " foo ".split(maxsplit=0)
|
||||
['foo ']
|
||||
|
||||
str.splitlines(keepends=False)
|
||||
|
||||
Return a list of the lines in the string, breaking at line
|
||||
|
|
@ -11724,8 +11798,15 @@ class dict(iterable, **kwargs)
|
|||
the keyword argument replaces the value from the positional
|
||||
argument.
|
||||
|
||||
To illustrate, the following examples all return a dictionary equal
|
||||
to "{"one": 1, "two": 2, "three": 3}":
|
||||
Providing keyword arguments as in the first example only works for
|
||||
keys that are valid Python identifiers. Otherwise, any valid keys
|
||||
can be used.
|
||||
|
||||
Dictionaries compare equal if and only if they have the same "(key,
|
||||
value)" pairs (regardless of ordering). Order comparisons (‘<’,
|
||||
‘<=’, ‘>=’, ‘>’) raise "TypeError". To illustrate dictionary
|
||||
creation and equality, the following examples all return a
|
||||
dictionary equal to "{"one": 1, "two": 2, "three": 3}":
|
||||
|
||||
>>> a = dict(one=1, two=2, three=3)
|
||||
>>> b = {'one': 1, 'two': 2, 'three': 3}
|
||||
|
|
@ -11740,6 +11821,29 @@ class dict(iterable, **kwargs)
|
|||
keys that are valid Python identifiers. Otherwise, any valid keys
|
||||
can be used.
|
||||
|
||||
Dictionaries preserve insertion order. Note that updating a key
|
||||
does not affect the order. Keys added after deletion are inserted
|
||||
at the end.
|
||||
|
||||
>>> d = {"one": 1, "two": 2, "three": 3, "four": 4}
|
||||
>>> d
|
||||
{'one': 1, 'two': 2, 'three': 3, 'four': 4}
|
||||
>>> list(d)
|
||||
['one', 'two', 'three', 'four']
|
||||
>>> list(d.values())
|
||||
[1, 2, 3, 4]
|
||||
>>> d["one"] = 42
|
||||
>>> d
|
||||
{'one': 42, 'two': 2, 'three': 3, 'four': 4}
|
||||
>>> del d["two"]
|
||||
>>> d["two"] = None
|
||||
>>> d
|
||||
{'one': 42, 'three': 3, 'four': 4, 'two': None}
|
||||
|
||||
Changed in version 3.7: Dictionary order is guaranteed to be
|
||||
insertion order. This behavior was an implementation detail of
|
||||
CPython from 3.6.
|
||||
|
||||
These are the operations that dictionaries support (and therefore,
|
||||
custom mapping types should support too):
|
||||
|
||||
|
|
@ -11910,33 +12014,6 @@ class dict(iterable, **kwargs)
|
|||
|
||||
Added in version 3.9.
|
||||
|
||||
Dictionaries compare equal if and only if they have the same "(key,
|
||||
value)" pairs (regardless of ordering). Order comparisons (‘<’,
|
||||
‘<=’, ‘>=’, ‘>’) raise "TypeError".
|
||||
|
||||
Dictionaries preserve insertion order. Note that updating a key
|
||||
does not affect the order. Keys added after deletion are inserted
|
||||
at the end.
|
||||
|
||||
>>> d = {"one": 1, "two": 2, "three": 3, "four": 4}
|
||||
>>> d
|
||||
{'one': 1, 'two': 2, 'three': 3, 'four': 4}
|
||||
>>> list(d)
|
||||
['one', 'two', 'three', 'four']
|
||||
>>> list(d.values())
|
||||
[1, 2, 3, 4]
|
||||
>>> d["one"] = 42
|
||||
>>> d
|
||||
{'one': 42, 'two': 2, 'three': 3, 'four': 4}
|
||||
>>> del d["two"]
|
||||
>>> d["two"] = None
|
||||
>>> d
|
||||
{'one': 42, 'three': 3, 'four': 4, 'two': None}
|
||||
|
||||
Changed in version 3.7: Dictionary order is guaranteed to be
|
||||
insertion order. This behavior was an implementation detail of
|
||||
CPython from 3.6.
|
||||
|
||||
Dictionaries and dictionary views are reversible.
|
||||
|
||||
>>> d = {"one": 1, "two": 2, "three": 3, "four": 4}
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue