Withdraw PEP 558 in favour of PEP 667 (GH-3762)

The original rationale for keeping PEP 558 open as an alternative to PEP 667
no longer applies, so withdrawn is a more appropriate state than deferred.

peps/pep-0558.rst

@@ -3,7 +3,7 @@ Title: Defined semantics for locals()
 Author: Alyssa Coghlan <ncoghlan@gmail.com>
 BDFL-Delegate: Nathaniel J. Smith
 Discussions-To: python-dev@python.org
-Status: Deferred
+Status: Withdrawn
 Type: Standards Track
 Content-Type: text/x-rst
 Created: 08-Sep-2017
@@ -11,32 +11,28 @@ Python-Version: 3.13
 Post-History: 08-Sep-2017, 22-May-2019, 30-May-2019, 30-Dec-2019, 18-Jul-2021,
               26-Aug-2021
 
-PEP Deferral
-============
+PEP Withdrawal
+==============
 
-While the original reference implementation for this PEP served a useful purpose
-in determining that it *is* feasible to solve the known problems with the
-semantics of the ``locals()`` namespace, that implementation itself is no longer
-viable as an implementation of the PEP as written.
+In December 2021, this PEP and :pep:`667` converged on a common definition of the
+proposed changes to the Python level semantics of the ``locals()`` builtin (as
+documented in the PEP text below), with the only remaining differences being
+in the proposed C API changes and various internal implementation details.
 
-This situation came about for two main reasons:
+Of those remaining differences, the most significant one was that :pep:`667`
+at the time still proposed an immediate backwards compatibility break for the
+``PyEval_GetLocals()`` API as soon as the PEP was accepted and implemented.
 
-* first, several key parts of the original implementation were invalidated when
-  the semantic improvements arising from the development of :pep:`667` resulted in
-  the proposal in the PEP diverging from what had previously been implemented
-* second, several remaining practical aspects of the original implementation were
-  invalidated by the frame management changes that formed part of the significant
-  performance improvements published in the CPython 3.11 release, so the development
-  branch doesn't even offer a useful starting point for an updated implementation
+:pep:`667` has since been changed to propose a generous deprecation period for
+the ``PyEval_GetLocals()`` API, continuing to support it in parallel with the
+improved semantics offered by the new ``PyEval_GetFrameLocals()`` API.
 
-As a result, further progress on this PEP requires the development of a new reference
-implementation, either for this PEP or for :pep:`667` (the semantics of the two PEPs
-are so close together now that an implementation for either would require only a few
-relatively small changes to instead implement the other).
+Any remaining C API design concerns relate to new informational APIs that can be
+added at a later date if they are deemed necessary, and any potential concerns
+about the exact performance characteristics of the frame locals view implementation
+are outweighed by the availability of a viable reference implementation.
 
-Since the PEP author has no current plans to produce that new reference implementation
-themselves, but the semantics proposed by the PEPs seem generally acceptable to the
-Python core development team, the most appropriate state for the PEP is "Deferred".
+Accordingly, this PEP has been withdrawn in favour of proceeding with :pep:`667`.
 
 Abstract
 ========
@@ -984,6 +980,10 @@ flexibility in how they provide those capabilities.
 Comparison with PEP 667
 -----------------------
 
+NOTE: the comparison below is against PEP 667 as it was in December 2021.
+It does not reflect the state of PEP 667 as of April 2024 (when this PEP was
+withdrawn in favour of proceeding with PEP 667).
+
 :pep:`667` offers a partially competing proposal for this PEP that suggests it
 would be reasonable to eliminate the internal frame value cache on optimised
 frames entirely.