iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

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

This commit is contained in:
Nick Coghlan 2023-03-11 17:49:43 +10:00 committed by GitHub
parent 26f6303d19
commit 900f32e8e1
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 28 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
pep-0558.rst
View File

@ -3,14 +3,40 @@ Title: Defined semantics for locals()
Author: Nick Coghlan <ncoghlan@gmail.com> Author: Nick Coghlan <ncoghlan@gmail.com>
BDFL-Delegate: Nathaniel J. Smith BDFL-Delegate: Nathaniel J. Smith
Discussions-To: python-dev@python.org Discussions-To: python-dev@python.org
Status: Draft Status: Deferred
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst Content-Type: text/x-rst
Created: 08-Sep-2017 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, Post-History: 08-Sep-2017, 22-May-2019, 30-May-2019, 30-Dec-2019, 18-Jul-2021,
26-Aug-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 Abstract
======== ========