(Replying here since b.p.o doesn't seem to want to let me log in)

I've used the PEP 523 API several times for multiple projects, from analyzing bytecode frequency (which probably could be done with other means) to inspecting type information from function calls. I could probably do such analysis a different way too, (some people do it via tracing). But from what I have experienced, the PEP 523 API is much faster than alternatives, and I would be sad to see it go. I also have written some of these experiments in Rust, and it would make it harder to use if I had to deal with enabling it. I would much prefer the proposed setters/getters.

Also the discussion is here for those who are interested https://bugs.python.org/issue38500

Best,
Ethan

On Thu, Nov 21, 2019 at 12:07 PM Brett Cannon <brett@python.org> wrote:
An unfortunate side-effect of making PyInterpreterState in Python 3.8 opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) support. https://www.python.org/dev/peps/pep-0523/ was opened to try and fix this, but there seems to be a stalemate in the issue.

A key question is at what API level should setting the frame evaluation function live at? No one is suggesting the stable ABI, but there isn't agreement between CPython or the internal API (there's also seems to be a suggestion to potentially remove PEP 523 support entirely).

And regardless of either, there also seems to be a disagreement about providing getters and setters to continue to try and hide PyInterpreterState regardless of which API level support is provided at (if any).

If you have an opinion please weight in on the issue.
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@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/4UZJYAZL3NHRAGN5WAMJC4IHAHEXF3QF/
Code of Conduct: http://python.org/psf/codeofconduct/