On Sat, 30 Jan 2021, 10:22 pm Mark Shannon, <mark@hotpy.org> wrote:
Hi Nick,
A couple more issues with PEP 558, as I see it.
Lack of specification ---------------------
There is no specification section in PEP 558.
Much of PEP 558 describes the differences between the current behavior and what PEP 558 proposes. These differences are often intermingled with a discussion of the flaws with the current behavior, which makes it difficult to understand what the proposed behavior is.
I could not implement PEP 558 from the PEP alone.
That's probably true, but as I wasn't trying to fully specify the implementation of the new C API, just describe the usage of it.
Cycles and the cost of maintaining the f_locals cache -----------------------------------------------------
PEP 558 proposes that f_locals acts as a proxy mapping to the locals in a frame *and* that the frame caches the proxy. This obviously creates a cycle, which needs to be broken by the cycle GC.
Although the cycle only exists if f_locals is actually used, there is still some overhead for *every* call and return, as the f_locals field needs to be initialized on call and checked for non-NULL on return.
Where does it still propose caching the proxy? You convinced me to take that out ages ago, and just store a plain dict instead, the same way Python 3.9 (et al) do. There was one remaining reference to cycle breaking, but the latest PR removes that. (That PR is still open, as it may yet move the new "Open Issue" to an actual design change). Cheers, Nick.