[Python-Dev] Stable ABI – PEP 667: Consistent views of namespaces

On 23. 08. 21 5:07, Guido van Rossum wrote:

On Sat, Aug 21, 2021 at 8:52 PM Nick Coghlan mailto:ncoghlan@gmail.com> wrote: [...] Code that uses PyEval_GetLocals() will NOT continue to operate safely under PEP 667: all such code will raise an exception at runtime, and need to be rewritten to use a new API with different refcounting semantics.

Yeah, I did a double take too when I read what Mark wrote. He uses "safe" in a very technical sense, meaning that you get a Python exception but not a crash, and no leak or writing freed memory. And it's true, any caller to PyEval_GetLocals() should check for errors, and there are several error conditions that may occur. (The docs are incomplete, they say "returns NULL if no frame is executing" but they fail to mention that it sets an exception in that case and in other cases.)

But PyEval_Locals() is in the Stable ABI (though I have no idea why),

This was a case of "now is better than never" – a line had to be drawn somewhere, and having a clear line is better than spending years to get the ideal line. For these PEPs, I think the discussion should stick to the desired semantics first; backwards compatibility for the Stable ABI can be bolted on to whatever solution comes up. "Regular" backwards compatibility is another matter – IMO it's important to keep things like debuggers working as much as possible.

we have essentially two options: keep it working, or make it return an error. We can't delete it. And it returns a borrowed reference, which makes it problematic to let it return a "f_locals proxy object" since those proxies are not cached on the frame.

From PEP 652 "Maintaining the Stable ABI":

Future Python versions may deprecate some members of the Stable ABI. Deprecated members will still work, but may suffer from issues like reduced performance or, in the most extreme cases, memory/resource leaks.

There are many things that can be done: - I believe we can add an extra pointer on frame objects, lazily populated, just for backward compatibility. - The bad old API can introduce a reference cycle. - We can incref the "borrowed" reference and introduce a leak. - The bad old API can start always raising an exception. (Last on the list, since if you can't fix the source and recompile an extension, there's no workaround.) In all cases, extension authors can fix things by moving to the new API.