diff --git a/peps/pep-0558.rst b/peps/pep-0558.rst index 71af552ef..5eb32ef68 100644 --- a/peps/pep-0558.rst +++ b/peps/pep-0558.rst @@ -3,7 +3,7 @@ Title: Defined semantics for locals() Author: Alyssa Coghlan 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.