On Thu, Aug 26, 2021 at 5:29 PM Nick Coghlan
[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-c...