Skip to content

Defer PEP 558 (defined semantics for locals()) once more #3050

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Mar 11, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 28 additions & 2 deletions pep-0558.rst
Original file line number Diff line number Diff line change
Expand Up @@ -3,14 +3,40 @@ Title: Defined semantics for locals()
Author: Nick Coghlan <[email protected]>
BDFL-Delegate: Nathaniel J. Smith
Discussions-To: [email protected]
Status: Draft
Status: Deferred
Type: Standards Track
Content-Type: text/x-rst
Created: 08-Sep-2017
Python-Version: 3.12
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
============

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.

This situation came about for two main reasons:

* first, several keys parts of the original implementation were invalidated when
the semantic improvements arising from the development of :pep:`667` resulted in
the PEP as written 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

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).

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".

Abstract
========
Expand Down