From 7b707b51a8497331a0713391038c3ceda7994d2b Mon Sep 17 00:00:00 2001 From: Nick Coghlan Date: Fri, 9 Jul 2021 11:03:09 +1000 Subject: [PATCH] PEP 558: Fix typos in recently merged changes (#2021) --- pep-0558.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/pep-0558.rst b/pep-0558.rst index 1f8c87a69..525b16086 100644 --- a/pep-0558.rst +++ b/pep-0558.rst @@ -359,7 +359,7 @@ API: * *fast_refs*: a mapping from variable names to either fast local storage offsets (for local variables) or to closure cells (for closure variables). This mapping is lazily initialized on the first access to the mapping, rather - being eagerly populated as soon as the proxy is created. + than being eagerly populated as soon as the proxy is created. ``__getitem__`` operations on the proxy will populate the ``fast_refs`` mapping (if it is not already populated), and then either return the relevant value @@ -384,7 +384,7 @@ For backwards compatibility with the existing ``PyEval_GetLocals()`` C API, the C level ``f_locals`` struct field does *not* store an instance of the new proxy type. In most cases the C level ``f_locals`` struct field will be ``NULL`` on an optimised frame, but if ``PyEval_GetLocals()`` is called, or -``PyFrame_LocalsToFast()`` or ``PyFrame_FastToLocalsWithError`` are called for +``PyFrame_FastToLocals()`` or ``PyFrame_FastToLocalsWithError()`` are called for any other reason (e.g. to resolve a Python level ``locals()`` builtin call), then the field will be populated with an implicitly updated snapshot of the local variables and closure references for the frame, just as it is today.