On Sat, Aug 14, 2021 at 8:01 PM Nick Coghlan <ncogh...@gmail.com> wrote:
> Bringing the public record up to date with a brief off-list discussion > between Mark, Nathaniel and I: > > * Mark hasn't convinced me that getting rid of the frame value cache > entirely for optimised frames is a good idea, so he's going to write that > proposal up as a competing PEP. Once it has been drafted and is ready for > review, he will request the SC assign a PEP delegate. > * On the PEP 558 front, Mark's proposal has highlighted a few > inefficiencies in my reference implementation, where the code still > implicitly updates the frame value cache in cases where the cache being up > to date may not matter to the proxy API client. So I'll be working on > another iteration of the implementation that ensures each caching proxy > instance (at worst) only pays the O(N) cache refresh price on the first > less than O(N) operation that relies on the cache being up to date, rather > than paying it every time "f_locals" is retrieved from the frame object. > > We still have plenty of time before 3.11b1, so we expect it will be a > month or two before the two proposals are in a position to be compared > directly. > I think I can speak for the SC by saying, "please, take as much time as you want" 😉. We are still trying to get out for our PEP review backlog as it is. -Brett > > Cheers, > Nick. > > On Fri, 30 Jul 2021, 5:25 pm Nick Coghlan, <ncogh...@gmail.com> wrote: > >> >> >> On Fri, 30 Jul 2021, 2:30 pm Nathaniel Smith, <n...@pobox.com> wrote: >> >>> >>> > >>> > For [proxy] versus [snapshot], a lot depends on what we think of >>> changing the semantics of exec(). [proxy] is definitely more consistent and >>> elegant, and if we could go back in time I think it's >>> what we'd have done from the start. Its compatibility is maybe a bit >>> worse than [snapshot] on non-exec() cases, but this seems pretty minor >>> overall (it often doesn't matter, and if it does just write >>> dict(locals()) instead of locals(), like you would in non-function >>> scope). But the change in exec() semantics is an actual language >>> change, even though it may not affect much real code, so that's what >>> stands out for me. >>> >>> I *think* (please correct me if I'm wrong) that what that calls >>> [PEP-minus-tracing] is now corresponds to the current PEP draft, and >>> [proxy] corresponds to Mark's draft at the beginning of this thread? >>> >> >> At the locals() level, PEP 558 is now [snapshot] (due to your original >> analysis showing that it was strictly better than what I had at the time), >> while Mark's draft is indeed [proxy]. >> >> Cheers, >> Nick. >> >> >> >>> -n >>> >>> -- >>> Nathaniel J. Smith -- https://vorpus.org >>> >> _______________________________________________ > 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/EU2TU6R2HDV6NLZQ56MSDIRMG6EHSOJO/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/U4K7OFXLQTNW667XAVEJPTPFSDTSWXB4/ Code of Conduct: http://python.org/psf/codeofconduct/
