On Fri, 30 Jul 2021, 6:05 am Mark Shannon, <m...@hotpy.org> wrote: > Hi Nick, > > Our discussion on PEP 558 got me thinking > "What is the simplest thing that would work?". > > This is what I came up (in the form of a draft PEP): > https://github.com/markshannon/peps/blob/pep-locals/pep-06xx.rst > > It doesn't have O(1) len(f_locals), and it does break > `PyEval_GetLocals()` but I think the that is a small price to pay for > simplicity and consistency. >
I don't think it is OK to break PyEval_GetLocals() when we really don't need to, and the proposal also discards all the feedback that I received on earlier iterations of PEP 558. (I particularly recommend reading Nathaniel's analysis of why returning the proxy from locals() would be more likely to cause bugs in existing code than it would be to eliminate any). As it looks like we have some fairly fundamental disagreements regarding the level of behaviour change and API breakage that is acceptable for the sake of a simpler implementation, I think we're going to need competing PEPs for the SC to evaluate (or delegate to Nathaniel for evaluation) if you want to pursue that path further. (I'm only OK with explicitly breaking PyEval_LocalsToFast because the write-back strategy is already intrinsically broken. By contrast, maintaining a frame cache for optimised frames isn't fundamentally flawed, it's just a matter of figuring out when and how to pay the cost of updating it to avoid wasting those CPU cycles in code that doesn't care if the cache is up to date or not) Cheers, Nick. > >
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/57BOZNO3GCVUDJ6FPF2OCKMTHE4U36Q2/ Code of Conduct: http://python.org/psf/codeofconduct/
