Python 3.14.0b1v3.14.0b1

1 files changed, 63 insertions, 46 deletions

diff --git a/Lib/pydoc_data/topics.py b/Lib/pydoc_data/topics.py
index 3f3d52dcc6b..5f7e14a79d3 100644
--- a/Lib/pydoc_data/topics.py
+++ b/Lib/pydoc_data/topics.py
@@ -1,4 +1,4 @@
-# Autogenerated by Sphinx on Tue Apr  8 14:20:44 2025
+# Autogenerated by Sphinx on Tue May  6 18:33:44 2025
 # as part of the release process.
 
 topics = {
@@ -1784,9 +1784,8 @@ Additional information on exceptions can be found in section
 Exceptions, and information on using the "raise" statement to generate
 exceptions may be found in section The raise statement.
 
-Changed in version 3.14.0a6 (unreleased): Support for optionally
-dropping grouping parentheses when using multiple exception types. See
-**PEP 758**.
+Changed in version 3.14: Support for optionally dropping grouping
+parentheses when using multiple exception types. See **PEP 758**.
 
 
 "except" clause
@@ -1976,9 +1975,9 @@ Changed in version 3.8: Prior to Python 3.8, a "continue" statement
 was illegal in the "finally" clause due to a problem with the
 implementation.
 
-Changed in version 3.14.0a6 (unreleased): The compiler emits a
-"SyntaxWarning" when a "return", "break" or "continue" appears in a
-"finally" block (see **PEP 765**).
+Changed in version 3.14: The compiler emits a "SyntaxWarning" when a
+"return", "break" or "continue" appears in a "finally" block (see
+**PEP 765**).
 
 
 The "with" statement
@@ -3933,6 +3932,19 @@ pdb.set_trace(*, header=None, commands=None)
 
    Added in version 3.14: The *commands* argument.
 
+awaitable pdb.set_trace_async(*, header=None, commands=None)
+
+   async version of "set_trace()". This function should be used inside
+   an async function with "await".
+
+      async def f():
+          await pdb.set_trace_async()
+
+   "await" statements are supported if the debugger is invoked by this
+   function.
+
+   Added in version 3.14.
+
 pdb.post_mortem(t=None)
 
    Enter post-mortem debugging of the given exception or traceback
@@ -3970,7 +3982,7 @@ The "run*" functions and "set_trace()" are aliases for instantiating
 the "Pdb" class and calling the method of the same name.  If you want
 to access further features, you have to do this yourself:
 
-class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=False, readrc=True, mode=None, backend=None)
+class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=False, readrc=True, mode=None, backend=None, colorize=False)
 
    "Pdb" is the debugger class.
 
@@ -4001,6 +4013,10 @@ class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=Fa
    See "set_default_backend()". Otherwise the supported backends are
    "'settrace'" and "'monitoring'".
 
+   The *colorize* argument, if set to "True", will enable colorized
+   output in the debugger, if color is supported. This will highlight
+   source code displayed in pdb.
+
    Example call to enable tracing with *skip*:
 
       import pdb; pdb.Pdb(skip=['django.*']).set_trace()
@@ -4018,6 +4034,8 @@ class pdb.Pdb(completekey='tab', stdin=None, stdout=None, skip=None, nosigint=Fa
 
    Added in version 3.14: Added the *backend* argument.
 
+   Added in version 3.14: Added the *colorize* argument.
+
    Changed in version 3.14: Inline breakpoints like "breakpoint()" or
    "pdb.set_trace()" will always stop the program at calling frame,
    ignoring the *skip* pattern (if any).
@@ -4496,7 +4514,7 @@ exceptions [excnumber]
    When using "pdb.pm()"  or "Pdb.post_mortem(...)" with a chained
    exception instead of a traceback, it allows the user to move
    between the chained exceptions using "exceptions" command to list
-   exceptions, and "exception <number>" to switch to that exception.
+   exceptions, and "exceptions <number>" to switch to that exception.
 
    Example:
 
@@ -6752,8 +6770,8 @@ object.__or__(self, other)
    called.  The "__divmod__()" method should be the equivalent to
    using "__floordiv__()" and "__mod__()"; it should not be related to
    "__truediv__()".  Note that "__pow__()" should be defined to accept
-   an optional third argument if the ternary version of the built-in
-   "pow()" function is to be supported.
+   an optional third argument if the three-argument version of the
+   built-in "pow()" function is to be supported.
 
    If one of those methods does not support the operation with the
    supplied arguments, it should return "NotImplemented".
@@ -6785,8 +6803,13 @@ object.__ror__(self, other)
    called if "type(x).__sub__(x, y)" returns "NotImplemented" or
    "type(y)" is a subclass of "type(x)". [5]
 
-   Note that ternary "pow()" will not try calling "__rpow__()" (the
-   coercion rules would become too complicated).
+   Note that "__rpow__()" should be defined to accept an optional
+   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.
 
    Note:
 
@@ -8785,8 +8808,8 @@ object.__or__(self, other)
    called.  The "__divmod__()" method should be the equivalent to
    using "__floordiv__()" and "__mod__()"; it should not be related to
    "__truediv__()".  Note that "__pow__()" should be defined to accept
-   an optional third argument if the ternary version of the built-in
-   "pow()" function is to be supported.
+   an optional third argument if the three-argument version of the
+   built-in "pow()" function is to be supported.
 
    If one of those methods does not support the operation with the
    supplied arguments, it should return "NotImplemented".
@@ -8818,8 +8841,13 @@ object.__ror__(self, other)
    called if "type(x).__sub__(x, y)" returns "NotImplemented" or
    "type(y)" is a subclass of "type(x)". [5]
 
-   Note that ternary "pow()" will not try calling "__rpow__()" (the
-   coercion rules would become too complicated).
+   Note that "__rpow__()" should be defined to accept an optional
+   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.
 
    Note:
 
@@ -10100,9 +10128,8 @@ Additional information on exceptions can be found in section
 Exceptions, and information on using the "raise" statement to generate
 exceptions may be found in section The raise statement.
 
-Changed in version 3.14.0a6 (unreleased): Support for optionally
-dropping grouping parentheses when using multiple exception types. See
-**PEP 758**.
+Changed in version 3.14: Support for optionally dropping grouping
+parentheses when using multiple exception types. See **PEP 758**.
 
 
 "except" clause
@@ -10292,9 +10319,9 @@ Changed in version 3.8: Prior to Python 3.8, a "continue" statement
 was illegal in the "finally" clause due to a problem with the
 implementation.
 
-Changed in version 3.14.0a6 (unreleased): The compiler emits a
-"SyntaxWarning" when a "return", "break" or "continue" appears in a
-"finally" block (see **PEP 765**).
+Changed in version 3.14: The compiler emits a "SyntaxWarning" when a
+"return", "break" or "continue" appears in a "finally" block (see
+**PEP 765**).
 ''',
     'types': r'''The standard type hierarchy
 ***************************
@@ -11141,25 +11168,15 @@ Special attributes
 |                                                    | collected during class body execution. See also:   |
 |                                                    | "__annotations__ attributes".  For best practices  |
 |                                                    | on working with "__annotations__", please see      |
-|                                                    | "annotationlib".  Caution:   Accessing the         |
-|                                                    | "__annotations__" attribute of a class object      |
-|                                                    | directly may yield incorrect results in the        |
-|                                                    | presence of metaclasses. In addition, the          |
-|                                                    | attribute may not exist for some classes. Use      |
-|                                                    | "annotationlib.get_annotations()" to retrieve      |
-|                                                    | class annotations safely.  Changed in version      |
-|                                                    | 3.14: Annotations are now lazily evaluated. See    |
-|                                                    | **PEP 649**.                                       |
+|                                                    | "annotationlib". Where possible, use               |
+|                                                    | "annotationlib.get_annotations()" instead of       |
+|                                                    | accessing this attribute directly.  Changed in     |
+|                                                    | version 3.14: Annotations are now lazily           |
+|                                                    | evaluated. See **PEP 649**.                        |
 +----------------------------------------------------+----------------------------------------------------+
 | type.__annotate__()                                | The *annotate function* for this class, or "None"  |
 |                                                    | if the class has no annotations. See also:         |
-|                                                    | "__annotate__ attributes".  Caution:   Accessing   |
-|                                                    | the "__annotate__" attribute of a class object     |
-|                                                    | directly may yield incorrect results in the        |
-|                                                    | presence of metaclasses. Use                       |
-|                                                    | "annotationlib.get_annotate_function()" to         |
-|                                                    | retrieve the annotate function safely.  Added in   |
-|                                                    | version 3.14.                                      |
+|                                                    | "__annotate__ attributes".  Added in version 3.14. |
 +----------------------------------------------------+----------------------------------------------------+
 | type.__type_params__                               | A "tuple" containing the type parameters of a      |
 |                                                    | generic class.  Added in version 3.12.             |
@@ -11355,16 +11372,16 @@ the "**keywords" syntax to accept arbitrary keyword arguments; bit
 Flags for details on the semantics of each flags that might be
 present.
 
-Future feature declarations ("from __future__ import division") also
-use bits in "co_flags" to indicate whether a code object was compiled
-with a particular feature enabled: bit "0x2000" is set if the function
-was compiled with future division enabled; bits "0x10" and "0x1000"
-were used in earlier versions of Python.
+Future feature declarations (for example, "from __future__ import
+division") also use bits in "co_flags" to indicate whether a code
+object was compiled with a particular feature enabled. See
+"compiler_flag".
 
 Other bits in "co_flags" are reserved for internal use.
 
-If a code object represents a function and has a docstring, the first
-item in "co_consts" is the docstring of the function.
+If a code object represents a function and has a docstring, the
+"CO_HAS_DOCSTRING" bit is set in "co_flags" and the first item in
+"co_consts" is the docstring of the function.
 
 
 Methods on code objects