PEP 558: Adopt Python level semantics from PEP 667

[ncoghlan]

• fast locals proxy never assumes the value cache is already up to date
• operations become O(n) as required to avoid that assumption
• remove *View() APIs from proposal due to algorithmic complexity issue
• add Python pseudo-code to the PEP 667 comparison section
• reword PEP 667 comparison section to focus on the remaining differences
  in the C API proposal

[gvanrossum]

Hi Nick, what are you waiting for here? I would like to get a decision from the SC before 3.11 goes into feature freeze, and I think the SC should be given at least two months lead time (they usually have a long queue and I don't want to get too close to the feature freeze deadline, as they have a tendency to suddenly push everything to the next release if something urgent comes up).

[ncoghlan]

@gvanrossum Sorry about that - I thought I had merged this when I made the original PR, but clearly I failed to come back and click the button after the build finished.

[gvanrossum]

NP -- happens to me all the time. :-)

I hope that at this point the differences between 558 and 667 are small enough that we can let python-dev pick a winner or forge a compromise (rather than taking a contentious choice to the SC).

[ncoghlan]

With any luck @markshannon will consider the proxy implementation oddities needed to keep the legacy API working acceptable now that they're not leaking through to the semantics of the new API anymore.

Then the C API break could be considered some time in the future strictly on its own merits (it would make the proxy implementation a bit cleaner and a bit faster on some operations, and I'd personally find the API break a lot more palatable if we did it only after the new API had already been available for a few releases)