I don't like the name_getfunc, as explained infaster-cpython/ideas#238 (comment)

Thanks, I'll go back to_getcaller based on the discussion on faster-cpython.

@markshannon would you still like this to make it into 3.11?

@JelleZijlstra I don't know about Mark, but personally I'd like to see it in 3.11. Would my review be enough? (I've held off reviewing since it's draft).

Unfortunately there are a few problems with this, which stem fromfunction.__code__ being mutable.

1. Promoting the use ofsys._getcaller instead ofsys._getframe is flawed when you want the code object, as the caller function's__code__ attribute may have changed so thatsys._getcaller(1).__code__ != sys.getframe(1).f_code which would be surprising. Changing the__code__ attribute of a function is a weird thing to do, so this might be OK.
2. As internal structs cease to be part of the C-API, we may be able to implementSpeed up frame handling in Python-to-Python calls. faster-cpython/ideas#111 which would mean that a reference to the caller function would no longer be available.
3. In terms of Python semantics, a frame is defined by the (code, globals, builtins, locals) quad, not by the function from which it originally derived. The API should probably reflect that.

This was my idea originally, sorry for not spotting these flaws earlier.

Then should we just close this?