Merge branch 'main' into gh-131263

Author: furkanonder

Doc/c-api/monitoring.rst

@@ -196,3 +196,15 @@ would typically correspond to a python function.
 .. c:function:: int PyMonitoring_ExitScope(void)
 
    Exit the last scope that was entered with :c:func:`!PyMonitoring_EnterScope`.
+
+
+.. c:function:: int PY_MONITORING_IS_INSTRUMENTED_EVENT(uint8_t ev)
+
+   Return true if the event corresponding to the event ID *ev* is
+   a :ref:`local event <monitoring-event-local>`.
+
+   .. versionadded:: 3.13
+
+   .. deprecated:: next
+
+      This function is :term:`soft deprecated`.

Doc/c-api/typeobj.rst

@@ -2,8 +2,8 @@
 
 .. _type-structs:
 
-Type Objects
-============
+Type Object Structures
+======================
 
 Perhaps one of the most important structures of the Python object system is the
 structure that defines a new type: the :c:type:`PyTypeObject` structure.  Type

Doc/c-api/unicode.rst

@@ -1868,7 +1868,7 @@ The following API is deprecated.
 
    .. versionadded:: 3.3
 
-   .. deprecated:: next
+   .. deprecated:: 3.14
       This API does nothing since Python 3.12.
       Previously, this could be called to check if
       :c:func:`PyUnicode_READY` is necessary.

Doc/conf.py

@@ -33,7 +33,6 @@
     'issue_role',
     'lexers',
     'misc_news',
-    'pydoc_topics',
     'pyspecific',
     'sphinx.ext.coverage',
     'sphinx.ext.doctest',

Doc/deprecations/pending-removal-in-3.15.rst

@@ -57,7 +57,7 @@ Pending removal in Python 3.15
 
 * :mod:`sysconfig`:
 
-  * The ``check_home`` argument of :func:`sysconfig.is_python_build` has been
+  * The *check_home* argument of :func:`sysconfig.is_python_build` has been
     deprecated since Python 3.12.
 
 * :mod:`threading`:

Doc/deprecations/pending-removal-in-future.rst

@@ -111,9 +111,6 @@ although there is currently no date scheduled for their removal.
   * ``ssl.TLSVersion.TLSv1``
   * ``ssl.TLSVersion.TLSv1_1``
 
-* :func:`sysconfig.is_python_build` *check_home* parameter is deprecated and
-  ignored.
-
 * :mod:`threading` methods:
 
   * :meth:`!threading.Condition.notifyAll`: use :meth:`~threading.Condition.notify_all`.

Doc/glossary.rst

@@ -800,6 +800,10 @@ Glossary
       thread removes *key* from *mapping* after the test, but before the lookup.
       This issue can be solved with locks or by using the EAFP approach.
 
+   lexical analyzer
+
+      Formal name for the *tokenizer*; see :term:`token`.
+
    list
       A built-in Python :term:`sequence`.  Despite its name it is more akin
       to an array in other languages than to a linked list since access to
@@ -1291,6 +1295,17 @@ Glossary
       See also :term:`binary file` for a file object able to read and write
       :term:`bytes-like objects <bytes-like object>`.
 
+   token
+
+      A small unit of source code, generated by the
+      :ref:`lexical analyzer <lexical>` (also called the *tokenizer*).
+      Names, numbers, strings, operators,
+      newlines and similar are represented by tokens.
+
+      The :mod:`tokenize` module exposes Python's lexical analyzer.
+      The :mod:`token` module contains information on the various types
+      of tokens.
+
    triple-quoted string
       A string which is bound by three instances of either a quotation mark
       (") or an apostrophe (').  While they don't provide any functionality

Doc/library/bdb.rst

@@ -118,7 +118,7 @@ The :mod:`bdb` module also defines two classes:
 
       Count of the number of times a :class:`Breakpoint` has been hit.
 
-.. class:: Bdb(skip=None)
+.. class:: Bdb(skip=None, backend='settrace')
 
    The :class:`Bdb` class acts as a generic Python debugger base class.
 
@@ -132,9 +132,22 @@ The :mod:`bdb` module also defines two classes:
    frame is considered to originate in a certain module is determined
    by the ``__name__`` in the frame globals.
 
+   The *backend* argument specifies the backend to use for :class:`Bdb`. It
+   can be either ``'settrace'`` or ``'monitoring'``. ``'settrace'`` uses
+   :func:`sys.settrace` which has the best backward compatibility. The
+   ``'monitoring'`` backend uses the new :mod:`sys.monitoring` that was
+   introduced in Python 3.12, which can be much more efficient because it
+   can disable unused events. We are trying to keep the exact interfaces
+   for both backends, but there are some differences. The debugger developers
+   are encouraged to use the ``'monitoring'`` backend to achieve better
+   performance.
+
    .. versionchanged:: 3.1
       Added the *skip* parameter.
 
+   .. versionchanged:: 3.14
+      Added the *backend* parameter.
+
    The following methods of :class:`Bdb` normally don't need to be overridden.
 
    .. method:: canonic(filename)
@@ -146,6 +159,20 @@ The :mod:`bdb` module also defines two classes:
       <os.path.abspath>`. A *filename* with angle brackets, such as ``"<stdin>"``
       generated in interactive mode, is returned unchanged.
 
+   .. method:: start_trace(self)
+
+      Start tracing. For ``'settrace'`` backend, this method is equivalent to
+      ``sys.settrace(self.trace_dispatch)``
+
+      .. versionadded:: 3.14
+
+   .. method:: stop_trace(self)
+
+      Stop tracing. For ``'settrace'`` backend, this method is equivalent to
+      ``sys.settrace(None)``
+
+      .. versionadded:: 3.14
+
    .. method:: reset()
 
       Set the :attr:`!botframe`, :attr:`!stopframe`, :attr:`!returnframe` and
@@ -364,6 +391,28 @@ The :mod:`bdb` module also defines two classes:
       Return all breakpoints that are set.
 
 
+   Derived classes and clients can call the following methods to disable and
+   restart events to achieve better performance. These methods only work
+   when using the ``'monitoring'`` backend.
+
+   .. method:: disable_current_event()
+
+      Disable the current event until the next time :func:`restart_events` is
+      called. This is helpful when the debugger is not interested in the current
+      line.
+
+      .. versionadded:: 3.14
+
+   .. method:: restart_events()
+
+      Restart all the disabled events. This function is automatically called in
+      ``dispatch_*`` methods after ``user_*`` methods are called. If the
+      ``dispatch_*`` methods are not overridden, the disabled events will be
+      restarted after each user interaction.
+
+      .. versionadded:: 3.14
+
+
    Derived classes and clients can call the following methods to get a data
    structure representing a stack trace.
 

Doc/library/cmdline.rst

@@ -12,7 +12,7 @@ The following modules have a command-line interface.
 * :ref:`compileall <compileall-cli>`
 * :mod:`cProfile`: see :ref:`profile <profile-cli>`
 * :ref:`dis <dis-cli>`
-* :mod:`doctest`
+* :ref:`doctest <doctest-cli>`
 * :mod:`!encodings.rot_13`
 * :mod:`ensurepip`
 * :mod:`filecmp`
@@ -25,7 +25,7 @@ The following modules have a command-line interface.
 * :ref:`json <json-commandline>`
 * :ref:`mimetypes <mimetypes-cli>`
 * :mod:`pdb`
-* :mod:`pickle`
+* :ref:`pickle <pickle-cli>`
 * :ref:`pickletools <pickletools-cli>`
 * :mod:`platform`
 * :mod:`poplib`

Doc/library/concurrent.futures.rst

@@ -73,7 +73,7 @@ Executor Objects
       .. versionchanged:: 3.5
          Added the *chunksize* parameter.
 
-      .. versionchanged:: next
+      .. versionchanged:: 3.14
          Added the *buffersize* parameter.
 
    .. method:: shutdown(wait=True, *, cancel_futures=False)
@@ -431,7 +431,7 @@ to a :class:`ProcessPoolExecutor` will result in deadlock.
       After calling this method the caller should no longer submit tasks to the
       executor.
 
-      .. versionadded:: next
+      .. versionadded:: 3.14
 
    .. method:: kill_workers()
 
@@ -443,7 +443,7 @@ to a :class:`ProcessPoolExecutor` will result in deadlock.
       After calling this method the caller should no longer submit tasks to the
       executor.
 
-      .. versionadded:: next
+      .. versionadded:: 3.14
 
 .. _processpoolexecutor-example: