python
diff --git a/‎peps/pep-0807.rst‎
Lines changed: 11 additions & 37 deletions b/‎peps/pep-0807.rst‎
Lines changed: 11 additions & 37 deletions
diff --git a/‎peps/pep-0810.rst‎
Lines changed: 19 additions & 1 deletion b/‎peps/pep-0810.rst‎
Lines changed: 19 additions & 1 deletion
@@ -125,6 +125,11 @@ apply to all parts of this PEP's specification:
   Receiving servers **SHOULD** respond with a ``406 Not Acceptable``
   status code if any other ``Accept`` header is present.
 
+* Unless otherwise specified, all error (4xx and 5xx) responses from the server
+  **MUST** use the :rfc:`9457` (Problem Details for HTTP APIs) format.
+  In particular, the server **MUST** use the "Problem Details JSON Object"
+  defined in :rfc:`Section 3 <9457#section-3>` and **SHOULD** use
+  the ``application/problem+json`` media type in its responses.
 
 Trusted Publishing Discovery
 ----------------------------
@@ -189,16 +194,10 @@ The discovery mechanism is as follows:
 
 If the server does not support Trusted Publishing for the given
 upload URL, it **MUST** respond with a ``404 Not Found`` status code.
-When responding with a ``404 Not Found``, the server **SHOULD NOT**
-include a response body. If a response body is included, it **MUST**
-be ignored by the client.
 
 Servers **MAY** additionally respond with any other standard HTTP
-error code in the 400 or 500 range to indicate an error condition.
-
-Non-``200 OK``, non-``404 Not Found`` responses **MAY** include a body which,
-if present, **MUST** be a JSON object containing an
-`Error Response <Error Responses_>`__.
+error code in the 400 or 500 range to indicate an appropriate error
+condition.
 
 Trusted Publishing Token Exchange
 ---------------------------------
@@ -233,11 +232,8 @@ containing a JSON object with the following field:
 
 - ``audience``: a string containing the expected OIDC audience.
 
-On failure, the server **MUST** respond with any standard HTTP
-error code in the 400 or 500 range to indicate an error condition.
-Failure responses **MAY** include a body which, if present,
-**MUST** be a JSON object containing an
-`Error Response <Error Responses_>`__.
+On failure, the server **MUST** respond with a standard HTTP
+error code in the 400 or 500 range to indicate the appropriate error condition.
 
 Token Minting
 ~~~~~~~~~~~~~
@@ -277,29 +273,7 @@ containing a JSON object with the following fields:
   above) to determine when to refresh the upload credential, if needed.
 
 On failure, the server **MUST** respond with any standard HTTP
-error code in the 400 or 500 range to indicate an error condition.
-Failure responses **MUST** include a body which, if present,
-**MUST** be a JSON object containing an `Error Response <Error Responses_>`__.
-
-Error Responses
----------------
-
-When an error response body is included, it **MUST** be a JSON object
-containing the following fields:
-
-- ``message``: a string containing a short, high-level
-    human-readable summary of the error.
-
-- ``errors``: an array of one or more objects, each containing
-    the following fields:
-
-    - ``code``: a string containing a machine-readable error code.
-    - ``description``: a string containing a human-readable
-      description of the error.
-
-This PEP does not specify any particular error codes. Clients **SHOULD NOT**
-assume that error codes are consistent across different indices, and instead
-**MUST** treat error codes as opaque strings.
+error code in the 400 or 500 range to indicate the appropriate error condition.
 
 Security Implications
 =====================
@@ -417,7 +391,7 @@ Footnotes
 
 .. [#fn-hash]
 
-   The discovery key may be computed thus:
+   The discovery key may be computed thusly:
 
    .. code-block:: pycon
 
 
@@ -8,12 +8,13 @@ Author: Pablo Galindo <pablogsal@python.org>,
         Noah Kim <noahbkim@gmail.com>,
         Tim Stumbaugh <me@tjstum.com>
 Discussions-To: https://discuss.python.org/t/104131
-Status: Draft
+Status: Accepted
 Type: Standards Track
 Created: 02-Oct-2025
 Python-Version: 3.15
 Post-History:
   `03-Oct-2025 <https://discuss.python.org/t/104131>`__,
+Resolution: `03-Nov-2025 <https://discuss.python.org/t/pep-810-explicit-lazy-imports/104131/466>`__
 
 
 Abstract
@@ -361,6 +362,15 @@ being imported, and (if applicable) the fromlist. An import remains lazy only
 if the filter function returns ``True``. If no lazy import filter is set, all
 *potentially lazy* imports are lazy.
 
+Note on .pth files
+~~~~~~~~~~~~~~~~~~
+
+The lazy import mechanism does not apply to .pth files processed by the
+``site`` module. While .pth files have special handling for lines that begin
+with ``import`` followed by a space or tab, this special handling will not be
+adapted to support lazy imports. Imports specified in .pth files remain eager
+as they always have been.
+
 Lazy objects
 ------------
 
@@ -617,6 +627,9 @@ lazy imports filter:
   ``"normal"`` (respect ``lazy`` keyword only), ``"all"`` (force all imports to be
   potentially lazy), or ``"none"`` (force all imports to be eager).
 
+* ``sys.get_lazy_imports()`` - Returns the current lazy imports mode as a
+  string: ``"normal"``, ``"all"``, or ``"none"``.
+
 The filter function is called for every potentially lazy import, and must
 return ``True`` if the import should be lazy. This allows for fine-grained
 control over which imports should be lazy, useful for excluding modules with
@@ -692,6 +705,11 @@ The global lazy imports flag can be controlled through:
 * The ``PYTHON_LAZY_IMPORTS=<mode>`` environment variable
 * The ``sys.set_lazy_imports(mode)`` function (primarily for testing)
 
+The precedence order for setting the lazy imports mode follows the standard
+Python pattern: ``sys.set_lazy_imports()`` takes highest precedence, followed
+by ``-X lazy_imports=<mode>``, then ``PYTHON_LAZY_IMPORTS=<mode>``. If none
+are specified, the mode defaults to ``"normal"``.
+
 Where ``<mode>`` can be:
 
 * ``"normal"`` (or unset): Only explicitly marked lazy imports are lazy