On 23. 08. 21 5:07, Guido van Rossum wrote:
On Sat, Aug 21, 2021 at 8:52 PM Nick Coghlan <ncogh...@gmail.com
<mailto:ncogh...@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.
_______________________________________________
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/LQARGPG4ROL6MJOQ4Y7CNT57TT7ON22S/
Code of Conduct: http://python.org/psf/codeofconduct/
