Add more docs

Author: pablogsal

Doc/library/sys.rst

@@ -1835,6 +1835,28 @@ always available. Unless explicitly noted otherwise, all variables are read-only
 
    .. versionadded:: 3.12
 
+
+.. function:: remote_exec(pid, script)
+
+   Executes a file containing Python code  given by *script* in the remote
+   process with the given *pid*.
+
+   This function returns immediately, and the code will be executed by the
+   target process's main thread at the next available opportunity, similarly
+   to how signals are handled. There is no interface to determine when the
+   code has been executed. The caller is responsible for making sure that
+   the file still exists whenever the remote process tries to read it and that
+   it hasn't been overwritten.
+
+   The remote process must be running a CPython interpreter of the same major
+   and minor version as the local process. If either the local or remote
+   interpreter is pre-release (alpha, beta, or release candidate) then the
+   local and remote interpreters must be the same exact version.
+
+   .. availability:: Unix, Windows.
+   .. versionadded:: 3.14
+
+
 .. function:: _enablelegacywindowsfsencoding()
 
    Changes the :term:`filesystem encoding and error handler` to 'mbcs' and

Doc/using/cmdline.rst

@@ -603,6 +603,13 @@ Miscellaneous options
 
      .. versionadded:: 3.13
 
+   * ``-X disable_remote_debug`` disables the remote debugging support as described
+     in :pep:`768`. This option is only available on some platforms and will do nothing
+     if is not supported on the current system. See also
+     :envvar:`PYTHON_DISABLE_REMOTE_DEBUG` and :pep:`768`.
+
+     .. versionadded:: 3.14
+
    * :samp:`-X cpu_count={n}` overrides :func:`os.cpu_count`,
      :func:`os.process_cpu_count`, and :func:`multiprocessing.cpu_count`.
      *n* must be greater than or equal to 1.
@@ -1160,7 +1167,14 @@ conflict.
 
    .. versionadded:: 3.13
 
+.. envvar:: PYTHON_DISABLE_REMOTE_DEBUG
+
+   If this variable is set to a non-empty string, it disables the remote
+   debugging feature described in :pep:`768`.
+
+   See also the :option:`-X disable_remote_debug` command-line option.
 
+   .. versionadded:: 3.14
 
 .. envvar:: PYTHON_CPU_COUNT
 

Doc/using/configure.rst

@@ -660,6 +660,15 @@ also be used to improve performance.
    Add ``-fstrict-overflow`` to the C compiler flags (by default we add
    ``-fno-strict-overflow`` instead).
 
+.. option:: --without-remote-debug
+
+   Deactivate remote debugging support described in :pep:`768` (enabled by default).
+   When this flag is provided the code that allows the interpreter to schedule the
+   execution of a Python file in a separate process as described in :pep:`768` is
+   not compiled.
+
+   ..versionadded:: 3.14
+
 
 .. _debug-build:
 

Doc/whatsnew/3.14.rst

@@ -90,6 +90,79 @@ If you encounter :exc:`NameError`\s or pickling errors coming out of
 New features
 ============
 
+.. _whatsnew314-pep678:
+
+PEP 768: Safe external debugger interface for CPython
+----------------------------------------------------
+
+:pep:`768` introduces a zero-overhead debugging interface that allows debuggers and profilers
+to safely attach to running Python processes. This is a significant enhancement to Python's
+debugging capabilities, bringing them in line with other major programming languages.
+
+The new interface provides safe execution points for attaching debugger code without modifying
+the interpreter's normal execution path or adding runtime overhead. This enables tools to
+inspect and interact with Python applications in real-time without stopping or restarting
+them — a crucial capability for high-availability systems and production environments.
+
+For convenience, CPython implements this interface through the :mod:`sys` module with a
+:func:`sys.remote_exec` function::
+
+    sys.remote_exec(pid, script_path)
+
+This function allows sending Python code to be executed in a target process at the next safe
+execution point. However, tool authors can also implement the protocol directly as described
+in the PEP, which details the underlying mechanisms used to safely attach to running processes.
+
+Here's a simple example that inspects object types in a running Python process:
+
+  .. code-block:: python
+
+    import sys
+    import tempfile
+    import os
+
+    # Create a temporary script
+    with tempfile.NamedTemporaryFile(mode='w', suffix='.py', delete=False) as f:
+        script_path = f.name
+        f.write("""
+    import gc
+    import collections
+
+    # Collect all objects managed by the garbage collector
+    gc.collect()
+
+    # Count objects by type
+    type_counts = collections.Counter(type(obj).__name__
+                                     for obj in gc.get_objects())
+
+    # Print the most common types
+    print("Most common object types in process:")
+    for type_name, count in type_counts.most_common(10):
+        print(f"  {type_name}: {count}")
+    """)
+
+    try:
+        # Execute in process with PID 1234
+        print("Behold! An offering:")
+        sys.remote_exec(1234, script_path)
+    finally:
+        os.unlink(script_path)
+
+The debugging interface has been carefully designed with security in mind and includes several
+mechanisms to control access:
+
+* A :envvar:`PYTHON_DISABLE_REMOTE_DEBUG` environment variable.
+* A :option:`-X disable-remote-debug` command-line option.
+* A ``--without-remote-debug`` configure flag to completely disable the feature at build time.
+
+A key implementation detail is that the interface piggybacks on the interpreter's existing evaluation
+loop and safe points, ensuring zero overhead during normal execution while providing a reliable way
+for external processes to coordinate debugging operations.
+
+See :pep:`768` for more details.
+
+(Contributed by Pablo Galindo Salgado, Matt Wozniski, and Ivona Stojanovic in :gh:`131591`.)
+
 .. _whatsnew314-pep649:
 
 PEP 649: deferred evaluation of annotations