Python 3.15.0a3v3.15.0a3

1 files changed, 420 insertions, 272 deletions

diff --git a/Lib/pydoc_data/topics.py b/Lib/pydoc_data/topics.py
index 11ffc6b..2f19e84 100644
--- a/Lib/pydoc_data/topics.py
+++ b/Lib/pydoc_data/topics.py
@@ -1,4 +1,4 @@
-# Autogenerated by Sphinx on Tue Nov 18 16:51:09 2025
+# Autogenerated by Sphinx on Tue Dec 16 14:26:04 2025
 # as part of the release process.
 
 topics = {
@@ -865,9 +865,9 @@ Notes on using *__slots__*:
   renders the meaning of the program undefined.  In the future, a
   check may be added to prevent this.
 
-* "TypeError" will be raised if nonempty *__slots__* are defined for a
-  class derived from a ""variable-length" built-in type" such as
-  "int", "bytes", and "tuple".
+* "TypeError" will be raised if *__slots__* other than *__dict__* and
+  *__weakref__* are defined for a class derived from a ""variable-
+  length" built-in type" such as "int", "bytes", and "tuple".
 
 * Any non-string *iterable* may be assigned to *__slots__*.
 
@@ -887,6 +887,9 @@ Notes on using *__slots__*:
 * If an *iterator* is used for *__slots__* then a *descriptor* is
   created for each of the iterator’s values. However, the *__slots__*
   attribute will be an empty iterator.
+
+Changed in version 3.15.0a2 (unreleased): Allowed defining the
+*__dict__* and *__weakref__* *__slots__* for any class.
 ''',
     'attribute-references': r'''Attribute references
 ********************
@@ -2112,7 +2115,7 @@ ensures that the type of the target "e" is consistently
    ... except* BlockingIOError as e:
    ...     print(repr(e))
    ...
-   ExceptionGroup('', (BlockingIOError()))
+   ExceptionGroup('', (BlockingIOError(),))
 
 "break", "continue" and "return" cannot appear in an "except*" clause.
 
@@ -2784,7 +2787,7 @@ a subject value:
    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.
@@ -2796,14 +2799,14 @@ a subject value:
         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.
 
@@ -2824,9 +2827,9 @@ a subject value:
 
         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:
@@ -6020,7 +6023,9 @@ The available presentation types for "float" and "Decimal" values are:
    |           | With no precision given, uses a precision of "6" digits    |
    |           | after the decimal point for "float", and shows all         |
    |           | coefficient digits for "Decimal".  If "p=0", the decimal   |
-   |           | point is omitted unless the "#" option is used.            |
+   |           | point is omitted unless the "#" option is used.  For       |
+   |           | "float", the exponent always contains at least two digits, |
+   |           | and is zero if the value is zero.                          |
    +-----------+------------------------------------------------------------+
    | "'E'"     | Scientific notation. Same as "'e'" except it uses an upper |
    |           | case ‘E’ as the separator character.                       |
@@ -6484,78 +6489,31 @@ trailing underscore characters:
 "NAME" tokens represent *identifiers*, *keywords*, and *soft
 keywords*.
 
-Within the ASCII range (U+0001..U+007F), the valid characters for
-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".
-
-Names must contain at least one character, but have no upper length
-limit. Case is significant.
-
-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.
-
-All identifiers are converted into the normalization form NFKC while
-parsing; comparison of identifiers is based on NFKC.
-
-Formally, the first character of a normalized identifier must belong
-to the set "id_start", which is the union of:
-
-* Unicode category "<Lu>" - uppercase letters (includes "A" to "Z")
-
-* Unicode category "<Ll>" - lowercase letters (includes "a" to "z")
+Names are composed of the following characters:
 
-* Unicode category "<Lt>" - titlecase letters
+* uppercase and lowercase letters ("A-Z" and "a-z"),
 
-* Unicode category "<Lm>" - modifier letters
+* the underscore ("_"),
 
-* Unicode category "<Lo>" - other letters
+* digits ("0" through "9"), which cannot appear as the first
+  character, and
 
-* Unicode category "<Nl>" - letter numbers
-
-* {""_""} - the underscore
-
-* "<Other_ID_Start>" - an explicit set of characters in PropList.txt
-  to support backwards compatibility
+* non-ASCII characters. Valid names may only contain “letter-like” and
+  “digit-like” characters; see Non-ASCII characters in names for
+  details.
 
-The remaining characters must belong to the set "id_continue", which
-is the union of:
-
-* all characters in "id_start"
-
-* Unicode category "<Nd>" - decimal numbers (includes "0" to "9")
-
-* Unicode category "<Pc>" - connector punctuations
-
-* 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.
+Names must contain at least one character, but have no upper length
+limit. Case is significant.
 
-Even more formally, names are described by the following lexical
-definitions:
+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>
+   NAME:          name_start name_continue*
+   name_start:    "a"..."z" | "A"..."Z" | "_" | <non-ASCII character>
+   name_continue: name_start | "0"..."9"
+   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.
+Note that not all names matched by this grammar are valid; see Non-
+ASCII characters in names for details.
 
 
 Keywords
@@ -6638,6 +6596,101 @@ trailing underscore characters:
    context of a class definition, are re-written to use a mangled form
    to help avoid name clashes between “private” attributes of base and
    derived classes. See section Identifiers (Names).
+
+
+Non-ASCII characters in names
+=============================
+
+Names that contain non-ASCII characters need additional normalization
+and validation beyond the rules and grammar explained above. For
+example, "ř_1", "蛇", or "साँप"  are valid names, but "r〰2", "€", or
+"🐍" are not.
+
+This section explains the exact rules.
+
+All names are converted into the normalization form NFKC while
+parsing. This means that, for example, some typographic variants of
+characters are converted to their “basic” form. For example,
+"fiⁿₐˡᵢᶻₐᵗᵢᵒₙ" normalizes to "finalization", so Python treats them as
+the same name:
+
+   >>> fiⁿₐˡᵢᶻₐᵗᵢᵒₙ = 3
+   >>> finalization
+   3
+
+Note:
+
+  Normalization is done at the lexical level only. Run-time functions
+  that take names as *strings* generally do not normalize their
+  arguments. For example, the variable defined above is accessible at
+  run time in the "globals()" dictionary as
+  "globals()["finalization"]" but not "globals()["fiⁿₐˡᵢᶻₐᵗᵢᵒₙ"]".
+
+Similarly to how ASCII-only names must contain only letters, digits
+and the underscore, and cannot start with a digit, a valid name must
+start with a character in the “letter-like” set "xid_start", and the
+remaining characters must be in the “letter- and digit-like” set
+"xid_continue".
+
+These sets based on the *XID_Start* and *XID_Continue* sets as defined
+by the Unicode standard annex UAX-31. Python’s "xid_start"
+additionally includes the underscore ("_"). Note that Python does not
+necessarily conform to UAX-31.
+
+A non-normative listing of characters in the *XID_Start* and
+*XID_Continue* sets as defined by Unicode is available in the
+DerivedCoreProperties.txt file in the Unicode Character Database. For
+reference, the construction rules for the "xid_*" sets are given
+below.
+
+The set "id_start" is defined as the union of:
+
+* Unicode category "<Lu>" - uppercase letters (includes "A" to "Z")
+
+* Unicode category "<Ll>" - lowercase letters (includes "a" to "z")
+
+* Unicode category "<Lt>" - titlecase letters
+
+* Unicode category "<Lm>" - modifier letters
+
+* Unicode category "<Lo>" - other letters
+
+* Unicode category "<Nl>" - letter numbers
+
+* {""_""} - the underscore
+
+* "<Other_ID_Start>" - an explicit set of characters in PropList.txt
+  to support backwards compatibility
+
+The set "xid_start" then closes this set under NFKC normalization, by
+removing all characters whose normalization is not of the form
+"id_start id_continue*".
+
+The set "id_continue" is defined as the union of:
+
+* "id_start" (see above)
+
+* Unicode category "<Nd>" - decimal numbers (includes "0" to "9")
+
+* Unicode category "<Pc>" - connector punctuations
+
+* 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
+
+Again, "xid_continue" closes this set under NFKC normalization.
+
+Unicode categories use the version of the Unicode Character Database
+as included in the "unicodedata" module.
+
+See also:
+
+  * **PEP 3131** – Supporting Non-ASCII Identifiers
+
+  * **PEP 672** – Unicode-related Security Considerations for Python
 ''',
     'if': r'''The "if" statement
 ******************
@@ -8956,9 +9009,9 @@ Notes on using *__slots__*:
   renders the meaning of the program undefined.  In the future, a
   check may be added to prevent this.
 
-* "TypeError" will be raised if nonempty *__slots__* are defined for a
-  class derived from a ""variable-length" built-in type" such as
-  "int", "bytes", and "tuple".
+* "TypeError" will be raised if *__slots__* other than *__dict__* and
+  *__weakref__* are defined for a class derived from a ""variable-
+  length" built-in type" such as "int", "bytes", and "tuple".
 
 * Any non-string *iterable* may be assigned to *__slots__*.
 
@@ -8979,6 +9032,9 @@ Notes on using *__slots__*:
   created for each of the iterator’s values. However, the *__slots__*
   attribute will be an empty iterator.
 
+Changed in version 3.15.0a2 (unreleased): Allowed defining the
+*__dict__* and *__weakref__* *__slots__* for any class.
+
 
 Customizing class creation
 ==========================
@@ -10150,10 +10206,14 @@ str.format(*args, **kwargs)
    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.
@@ -10208,13 +10268,28 @@ str.isalpha()
    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.
 
@@ -10223,8 +10298,16 @@ str.isdecimal()
    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()
 
@@ -10267,7 +10350,19 @@ str.isnumeric()
    that have the Unicode numeric value property, e.g. U+2155, VULGAR
    FRACTION ONE FIFTH.  Formally, numeric characters are those with
    the property value Numeric_Type=Digit, Numeric_Type=Decimal or
-   Numeric_Type=Numeric.
+   Numeric_Type=Numeric. For example:
+
+      >>> '0123456789'.isnumeric()
+      True
+      >>> '٠١٢٣٤٥٦٧٨٩'.isnumeric()  # Arabic-indic digit zero to nine
+      True
+      >>> '⅕'.isnumeric()  # Vulgar fraction one fifth
+      True
+      >>> '²'.isdecimal(), '²'.isdigit(),  '²'.isnumeric()
+      (False, True, True)
+
+   See also "isdecimal()" and "isdigit()". Numeric characters are a
+   superset of decimal numbers.
 
 str.isprintable()
 
@@ -10333,7 +10428,15 @@ str.join(iterable, /)
    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=' ', /)
 
@@ -10342,6 +10445,17 @@ str.ljust(width, fillchar=' ', /)
    space). The original string is returned if *width* is less than or
    equal to "len(s)".
 
+   For example:
+
+      >>> 'Python'.ljust(10)
+      'Python    '
+      >>> 'Python'.ljust(10, '.')
+      'Python....'
+      >>> 'Monty Python'.ljust(10, '.')
+      'Monty Python'
+
+   See also "rjust()".
+
 str.lower()
 
    Return a copy of the string with all the cased characters [4]
@@ -10543,6 +10657,8 @@ str.split(sep=None, maxsplit=-1)
       >>> "   foo   ".split(maxsplit=0)
       ['foo   ']
 
+   See also "join()".
+
 str.splitlines(keepends=False)
 
    Return a list of the lines in the string, breaking at line
@@ -11046,119 +11162,56 @@ f-strings
 
 Added in version 3.6.
 
-A *formatted string literal* or *f-string* is a string literal that is
-prefixed with ‘"f"’ or ‘"F"’.  These strings may contain replacement
-fields, which are expressions delimited by curly braces "{}". While
-other string literals always have a constant value, formatted strings
-are really expressions evaluated at run time.
-
-Escape sequences are decoded like in ordinary string literals (except
-when a literal is also marked as a raw string).  After decoding, the
-grammar for the contents of the string is:
-
-   f_string:          (literal_char | "{{" | "}}" | replacement_field)*
-   replacement_field: "{" f_expression ["="] ["!" conversion] [":" format_spec] "}"
-   f_expression:      (conditional_expression | "*" or_expr)
-                        ("," conditional_expression | "," "*" or_expr)* [","]
-                      | yield_expression
-   conversion:        "s" | "r" | "a"
-   format_spec:       (literal_char | replacement_field)*
-   literal_char:      <any code point except "{", "}" or NULL>
-
-The parts of the string outside curly braces are treated literally,
-except that any doubled curly braces "'{{'" or "'}}'" are replaced
-with the corresponding single curly brace.  A single opening curly
-bracket "'{'" marks a replacement field, which starts with a Python
-expression. To display both the expression text and its value after
-evaluation, (useful in debugging), an equal sign "'='" may be added
-after the expression. A conversion field, introduced by an exclamation
-point "'!'" may follow.  A format specifier may also be appended,
-introduced by a colon "':'". A replacement field ends with a closing
-curly bracket "'}'".
-
-Expressions in formatted string literals are treated like regular
-Python expressions surrounded by parentheses, with a few exceptions.
-An empty expression is not allowed, and both "lambda"  and assignment
-expressions ":=" must be surrounded by explicit parentheses. Each
-expression is evaluated in the context where the formatted string
-literal appears, in order from left to right.  Replacement expressions
-can contain newlines in both single-quoted and triple-quoted f-strings
-and they can contain comments.  Everything that comes after a "#"
-inside a replacement field is a comment (even closing braces and
-quotes). In that case, replacement fields must be closed in a
-different line.
-
-   >>> f"abc{a # This is a comment }"
-   ... + 3}"
-   'abc5'
-
-Changed in version 3.7: Prior to Python 3.7, an "await" expression and
-comprehensions containing an "async for" clause were illegal in the
-expressions in formatted string literals due to a problem with the
-implementation.
-
-Changed in version 3.12: Prior to Python 3.12, comments were not
-allowed inside f-string replacement fields.
+Changed in version 3.7: The "await" and "async for" can be used in
+expressions within f-strings.
 
-When the equal sign "'='" is provided, the output will have the
-expression text, the "'='" and the evaluated value. Spaces after the
-opening brace "'{'", within the expression and after the "'='" are all
-retained in the output. By default, the "'='" causes the "repr()" of
-the expression to be provided, unless there is a format specified.
-When a format is specified it defaults to the "str()" of the
-expression unless a conversion "'!r'" is declared.
+Changed in version 3.8: Added the debug specifier ("=")
 
-Added in version 3.8: The equal sign "'='".
+Changed in version 3.12: Many restrictions on expressions within
+f-strings have been removed. Notably, nested strings, comments, and
+backslashes are now permitted.
 
-If a conversion is specified, the result of evaluating the expression
-is converted before formatting.  Conversion "'!s'" calls "str()" on
-the result, "'!r'" calls "repr()", and "'!a'" calls "ascii()".
+A *formatted string literal* or *f-string* is a string literal that is
+prefixed with ‘"f"’ or ‘"F"’. Unlike other string literals, f-strings
+do not have a constant value. They may contain *replacement fields*
+delimited by curly braces "{}". Replacement fields contain expressions
+which are evaluated at run time. For example:
+
+   >>> who = 'nobody'
+   >>> nationality = 'Spanish'
+   >>> f'{who.title()} expects the {nationality} Inquisition!'
+   'Nobody expects the Spanish Inquisition!'
+
+Any doubled curly braces ("{{" or "}}") outside replacement fields are
+replaced with the corresponding single curly brace:
+
+   >>> print(f'{{...}}')
+   {...}
+
+Other characters outside replacement fields are treated like in
+ordinary string literals. This means that escape sequences are decoded
+(except when a literal is also marked as a raw string), and newlines
+are possible in triple-quoted f-strings:
+
+   >>> name = 'Galahad'
+   >>> favorite_color = 'blue'
+   >>> print(f'{name}:\\t{favorite_color}')
+   Galahad:       blue
+   >>> print(rf"C:\\Users\\{name}")
+   C:\\Users\\Galahad
+   >>> print(f\'\'\'Three shall be the number of the counting
+   ... and the number of the counting shall be three.\'\'\')
+   Three shall be the number of the counting
+   and the number of the counting shall be three.
 
-The result is then formatted using the "format()" protocol.  The
-format specifier is passed to the "__format__()" method of the
-expression or conversion result.  An empty string is passed when the
-format specifier is omitted.  The formatted result is then included in
-the final value of the whole string.
+Expressions in formatted string literals are treated like regular
+Python expressions. Each expression is evaluated in the context where
+the formatted string literal appears, in order from left to right. An
+empty expression is not allowed, and both "lambda" and assignment
+expressions ":=" must be surrounded by explicit parentheses:
 
-Top-level format specifiers may include nested replacement fields.
-These nested fields may include their own conversion fields and format
-specifiers, but may not include more deeply nested replacement fields.
-The format specifier mini-language is the same as that used by the
-"str.format()" method.
-
-Formatted string literals may be concatenated, but replacement fields
-cannot be split across literals.
-
-Some examples of formatted string literals:
-
-   >>> name = "Fred"
-   >>> f"He said his name is {name!r}."
-   "He said his name is 'Fred'."
-   >>> f"He said his name is {repr(name)}."  # repr() is equivalent to !r
-   "He said his name is 'Fred'."
-   >>> width = 10
-   >>> precision = 4
-   >>> value = decimal.Decimal("12.34567")
-   >>> f"result: {value:{width}.{precision}}"  # nested fields
-   'result:      12.35'
-   >>> today = datetime(year=2017, month=1, day=27)
-   >>> f"{today:%B %d, %Y}"  # using date format specifier
-   'January 27, 2017'
-   >>> f"{today=:%B %d, %Y}" # using date format specifier and debugging
-   'today=January 27, 2017'
-   >>> number = 1024
-   >>> f"{number:#0x}"  # using integer format specifier
-   '0x400'
-   >>> foo = "bar"
-   >>> f"{ foo = }" # preserves whitespace
-   " foo = 'bar'"
-   >>> line = "The mill's closed"
-   >>> f"{line = }"
-   'line = "The mill\\'s closed"'
-   >>> f"{line = :20}"
-   "line = The mill's closed   "
-   >>> f"{line = !r:20}"
-   'line = "The mill\\'s closed" '
+   >>> f'{(half := 1/2)}, {half * 42}'
+   '0.5, 21.0'
 
 Reusing the outer f-string quoting type inside a replacement field is
 permitted:
@@ -11167,10 +11220,6 @@ permitted:
    >>> f"abc {a["x"]} def"
    'abc 2 def'
 
-Changed in version 3.12: Prior to Python 3.12, reuse of the same
-quoting type of the outer f-string inside a replacement field was not
-possible.
-
 Backslashes are also allowed in replacement fields and are evaluated
 the same way as in any other context:
 
@@ -11181,21 +11230,84 @@ the same way as in any other context:
    b
    c
 
-Changed in version 3.12: Prior to Python 3.12, backslashes were not
-permitted inside an f-string replacement field.
+It is possible to nest f-strings:
+
+   >>> name = 'world'
+   >>> f'Repeated:{f' hello {name}' * 3}'
+   'Repeated: hello world hello world hello world'
+
+Portable Python programs should not use more than 5 levels of nesting.
+
+**CPython implementation detail:** CPython does not limit nesting of
+f-strings.
+
+Replacement expressions can contain newlines in both single-quoted and
+triple-quoted f-strings and they can contain comments. Everything that
+comes after a "#" inside a replacement field is a comment (even
+closing braces and quotes). This means that replacement fields with
+comments must be closed in a different line:
+
+   >>> a = 2
+   >>> f"abc{a  # This comment  }"  continues until the end of the line
+   ...       + 3}"
+   'abc5'
+
+After the expression, replacement fields may optionally contain:
+
+* a *debug specifier* – an equal sign ("="), optionally surrounded by
+  whitespace on one or both sides;
+
+* a *conversion specifier* – "!s", "!r" or "!a"; and/or
+
+* a *format specifier* prefixed with a colon (":").
 
-Formatted string literals cannot be used as docstrings, even if they
-do not include expressions.
+See the Standard Library section on f-strings for details on how these
+fields are evaluated.
+
+As that section explains, *format specifiers* are passed as the second
+argument to the "format()" function to format a replacement field
+value. For example, they can be used to specify a field width and
+padding characters using the Format Specification Mini-Language:
+
+   >>> number = 14.3
+   >>> f'{number:20.7f}'
+   '          14.3000000'
+
+Top-level format specifiers may include nested replacement fields:
+
+   >>> field_size = 20
+   >>> precision = 7
+   >>> f'{number:{field_size}.{precision}f}'
+   '          14.3000000'
+
+These nested fields may include their own conversion fields and format
+specifiers:
+
+   >>> number = 3
+   >>> f'{number:{field_size}}'
+   '                   3'
+   >>> f'{number:{field_size:05}}'
+   '00000000000000000003'
+
+However, these nested fields may not include more deeply nested
+replacement fields.
+
+Formatted string literals cannot be used as *docstrings*, even if they
+do not include expressions:
 
    >>> def foo():
    ...     f"Not a docstring"
    ...
-   >>> foo.__doc__ is None
-   True
+   >>> print(foo.__doc__)
+   None
+
+See also:
 
-See also **PEP 498** for the proposal that added formatted string
-literals, and "str.format()", which uses a related format string
-mechanism.
+  * **PEP 498** – Literal String Interpolation
+
+  * **PEP 701** – Syntactic formalization of f-strings
+
+  * "str.format()", which uses a related format string mechanism.
 
 
 t-strings
@@ -11204,34 +11316,90 @@ t-strings
 Added in version 3.14.
 
 A *template string literal* or *t-string* is a string literal that is
-prefixed with ‘"t"’ or ‘"T"’. These strings follow the same syntax and
-evaluation rules as formatted string literals, with the following
-differences:
-
-* Rather than evaluating to a "str" object, template string literals
-  evaluate to a "string.templatelib.Template" object.
-
-* The "format()" protocol is not used. Instead, the format specifier
-  and conversions (if any) are passed to a new "Interpolation" object
-  that is created for each evaluated expression. It is up to code that
-  processes the resulting "Template" object to decide how to handle
-  format specifiers and conversions.
-
-* Format specifiers containing nested replacement fields are evaluated
-  eagerly, prior to being passed to the "Interpolation" object. For
-  instance, an interpolation of the form "{amount:.{precision}f}" will
-  evaluate the inner expression "{precision}" to determine the value
-  of the "format_spec" attribute. If "precision" were to be "2", the
-  resulting format specifier would be "'.2f'".
-
-* When the equals sign "'='" is provided in an interpolation
-  expression, the text of the expression is appended to the literal
-  string that precedes the relevant interpolation. This includes the
-  equals sign and any surrounding whitespace. The "Interpolation"
-  instance for the expression will be created as normal, except that
-  "conversion" will be set to ‘"r"’ ("repr()") by default. If an
-  explicit conversion or format specifier are provided, this will
-  override the default behaviour.
+prefixed with ‘"t"’ or ‘"T"’. These strings follow the same syntax
+rules as formatted string literals. For differences in evaluation
+rules, see the Standard Library section on t-strings
+
+
+Formal grammar for f-strings
+============================
+
+F-strings are handled partly by the *lexical analyzer*, which produces
+the tokens "FSTRING_START", "FSTRING_MIDDLE" and "FSTRING_END", and
+partly by the parser, which handles expressions in the replacement
+field. The exact way the work is split is a CPython implementation
+detail.
+
+Correspondingly, the f-string grammar is a mix of lexical and
+syntactic definitions.
+
+Whitespace is significant in these situations:
+
+* There may be no whitespace in "FSTRING_START" (between the prefix
+  and quote).
+
+* Whitespace in "FSTRING_MIDDLE" is part of the literal string
+  contents.
+
+* In "fstring_replacement_field", if "f_debug_specifier" is present,
+  all whitespace after the opening brace until the
+  "f_debug_specifier", as well as whitespace immediately following
+  "f_debug_specifier", is retained as part of the expression.
+
+  **CPython implementation detail:** The expression is not handled in
+  the tokenization phase; it is retrieved from the source code using
+  locations of the "{" token and the token after "=".
+
+The "FSTRING_MIDDLE" definition uses negative lookaheads ("!") to
+indicate special characters (backslash, newline, "{", "}") and
+sequences ("f_quote").
+
+   fstring:    FSTRING_START fstring_middle* FSTRING_END
+
+   FSTRING_START:      fstringprefix ("'" | '"' | "\'\'\'" | '"""')
+   FSTRING_END:        f_quote
+   fstringprefix:      <("f" | "fr" | "rf"), case-insensitive>
+   f_debug_specifier:  '='
+   f_quote:            <the quote character(s) used in FSTRING_START>
+
+   fstring_middle:
+      | fstring_replacement_field
+      | FSTRING_MIDDLE
+   FSTRING_MIDDLE:
+      | (!"\\" !newline !'{' !'}' !f_quote) source_character
+      | stringescapeseq
+      | "{{"
+      | "}}"
+      | <newline, in triple-quoted f-strings only>
+   fstring_replacement_field:
+      | '{' f_expression [f_debug_specifier] [fstring_conversion]
+            [fstring_full_format_spec] '}'
+   fstring_conversion:
+      | "!" ("s" | "r" | "a")
+   fstring_full_format_spec:
+      | ':' fstring_format_spec*
+   fstring_format_spec:
+      | FSTRING_MIDDLE
+      | fstring_replacement_field
+   f_expression:
+      | ','.(conditional_expression | "*" or_expr)+ [","]
+      | yield_expression
+
+Note:
+
+  In the above grammar snippet, the "f_quote" and "FSTRING_MIDDLE"
+  rules are context-sensitive – they depend on the contents of
+  "FSTRING_START" of the nearest enclosing "fstring".Constructing a
+  more traditional formal grammar from this template is left as an
+  exercise for the reader.
+
+The grammar for t-strings is identical to the one for f-strings, with
+*t* instead of *f* at the beginning of rule and token names and in the
+prefix.
+
+   tstring:    TSTRING_START tstring_middle* TSTRING_END
+
+   <rest of the t-string grammar is omitted; see above>
 ''',
     'subscriptions': r'''Subscriptions
 *************
@@ -11480,7 +11648,7 @@ ensures that the type of the target "e" is consistently
    ... except* BlockingIOError as e:
    ...     print(repr(e))
    ...
-   ExceptionGroup('', (BlockingIOError()))
+   ExceptionGroup('', (BlockingIOError(),))
 
 "break", "continue" and "return" cannot appear in an "except*" clause.
 
@@ -11790,7 +11958,7 @@ There are currently two intrinsic set types:
 Sets
    These represent a mutable set. They are created by the built-in
    "set()" constructor and can be modified afterwards by several
-   methods, such as "add".
+   methods, such as "add()".
 
 Frozen sets
    These represent an immutable set.  They are created by the built-in
@@ -12239,41 +12407,25 @@ module.__path__
 
 module.__file__
 
-module.__cached__
-
-   "__file__" and "__cached__" are both optional attributes that may
-   or may not be set. Both attributes should be a "str" when they are
-   available.
-
-   "__file__" indicates the pathname of the file from which the module
-   was loaded (if loaded from a file), or the pathname of the shared
-   library file for extension modules loaded dynamically from a shared
-   library. It might be missing for certain types of modules, such as
-   C modules that are statically linked into the interpreter, and the
-   import system may opt to leave it unset if it has no semantic
-   meaning (for example, a module loaded from a database).
-
-   If "__file__" is set then the "__cached__" attribute might also be
-   set,  which is the path to any compiled version of the code (for
-   example, a byte-compiled file). The file does not need to exist to
-   set this attribute; the path can simply point to where the compiled
-   file *would* exist (see **PEP 3147**).
-
-   Note that "__cached__" may be set even if "__file__" is not set.
-   However, that scenario is quite atypical.  Ultimately, the *loader*
-   is what makes use of the module spec provided by the *finder* (from
-   which "__file__" and "__cached__" are derived).  So if a loader can
-   load from a cached module but otherwise does not load from a file,
-   that atypical scenario may be appropriate.
+   "__file__" is an optional attribute that may or may not be set.
+   Both attributes should be a "str" when they are available.
 
-   It is **strongly** recommended that you use
-   "module.__spec__.cached" instead of "module.__cached__".
+   An optional attribute, "__file__" indicates the pathname of the
+   file from which the module was loaded (if loaded from a file), or
+   the pathname of the shared library file for extension modules
+   loaded dynamically from a shared library. It might be missing for
+   certain types of modules, such as C modules that are statically
+   linked into the interpreter, and the import system may opt to leave
+   it unset if it has no semantic meaning (for example, a module
+   loaded from a database).
 
    Deprecated since version 3.13, removed in version 3.15: Setting
    "__cached__" on a module while failing to set "__spec__.cached" is
    deprecated. In Python 3.15, "__cached__" will cease to be set or
    taken into consideration by the import system or standard library.
 
+   Changed in version 3.15: "__cached__" is no longer set.
+
 
 Other writable attributes on module objects
 -------------------------------------------
@@ -12957,10 +13109,6 @@ class dict(iterable, /, **kwargs)
    the keyword argument replaces the value from the positional
    argument.
 
-   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