On Thu, Aug 26, 2021 at 5:29 PM Nick Coghlan <ncogh...@gmail.com> wrote:
> [snip] > For the main topic of PEP 667 (reducing the cache consistency question to > purely a matter of PyEval_GetLocals() compatibility), I think I can see a > way to make the extra code complexity of the 5 new custom accessory types > (iterator, reversed iterator, keys set, values multi set, items set) > worthwhile to my mind: write the latter 3 in terms of the first two and the > generic mapping API, and expose them for use in other custom mapping > implementations (either directly in the types module, or as optional C > accelerators for the collections module). (I wouldn't make exposing them > part of the PEP, I'd just aim to write them so only the forward and reverse > iterators were specific to proxy objects) > Yes, that makes sense. I wouldn't sweat it though. > With that done, popitem() is trivial to rewrite to depend on the iterator > code instead of the cache. > > That would leave len() and value comparison as the only proxy operations > that don't adhere to the expected algorithmic complexity of mapping > objects, and writing up the comparison with PEP 667 finally convinced me > that those are quirks that API users could manage more easily than 558's > current lazy caching semantics. > That's what we've been saying. :-) I'd still keep the full value cache under the hood, though, as I don't see > enough benefit in getting rid of it when the cost is an unnecessary API > compatibility break. > That's for PyEval_GetLocals(), right? Mark updated PEP 667 to also keep a reference to whatever it returned on the frame. So then I think the two PEPs have converged. > However, the PEP 667 write up and your own points *have* persuaded me that > the extra C code needed to offer assuredly consistent views through all the > proxy mapping methods is worthwhile. > Right. That will then leave the proposed C APIs as the only differences between > the PEPs - the Python level behaviour will be aligned with Mark's proposal. > Yeah, I presume that the *new* APIs proposed are just a matter of a little bikeshedding, nothing major. > Cheers, > Nick. > Thanks for your flexibility! > P.S. I don't want to rely on Python code anywhere in the fast locals proxy > implementation, as that could cause weird interactions if a trace hook is > enabled during the initial start up of the interpreter and tries to trace > the proxy implementation code. > Of course. But it would still be interesting to have pseudo-code in your PEP showing the semantics you intend to implement -- that way we can compare 558 and 667 more easily. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
_______________________________________________ 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/P37GSW6BHHZGRQNZECMHJEWG3WDEGFDR/ Code of Conduct: http://python.org/psf/codeofconduct/
