On Sat, Aug 14, 2021 at 8:01 PM Nick Coghlan <[email protected]> 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 2021εΉ΄7ζ30ζ₯, 5:25 pm Nick Coghlan, <[email protected]> wrote: > >> >> >> On 2021εΉ΄7ζ30ζ₯, 2:30 pm Nathaniel Smith, <[email protected]> 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 -- [email protected] > To unsubscribe send an email to [email protected] > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/[email protected]/message/EU2TU6R2HDV6NLZQ56MSDIRMG6EHSOJO/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-Dev mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/U4K7OFXLQTNW667XAVEJPTPFSDTSWXB4/ Code of Conduct: http://python.org/psf/codeofconduct/