Add getouterframe function to inspect module

[rprater]

Currently, the inspect module has the getouterframes function which gets a list of FrameInfo objects for a frame and all outer frames. However, there is no function that just gets the next outer frame (the current frame’s caller).

It is possible to get that frame by using the f_back attribute from the frame object and then convert the resulting object into a FrameInfo instance. However, that does seem less optimal and it would be much easier to just have a getouterframe function.

I would very much like to take on creating the getouterframe function.

[carljm]

So the proposed function would effectively be a shortcut for inspect.getframeinfo(inspect.currentframe().f_back) (or perhaps more simply, inspect.getframeinfo(sys._getframe(1))?

(I realize that getframeinfo returns a Traceback not a FrameInfo, but the only difference is the latter includes the frame object, which you already have in hand if you're calling inspect.currentframe().)

It feels like the inspect module already provides the necessary primitives here, and I'm not sure the existing spellings of this are so onerous that it's worth adding a new function to the module. On the other hand, I recognize that "get my caller" is likely a common operation as far as stack-walking goes, so it may be worth dedicated API.

One potential point of confusion in the proposed API is that getouterframes takes a frame (so it doesn't directly depend on the availability of sys._getframe(), and instead requires that you already have a frame object in hand, or call currentframe() yourself.) If the proposed getouterframe() implicitly calls currentframe(), that's an awkward difference in behavior from getouterframes(), for such similar names. If it doesn't implicitly call currentframe(), then it really doesn't save much over the existing ways of doing the same thing.

It's often useful to propose new feature ideas at https://discuss.python.org/c/ideas/6 where they get a bit more visibility, so you can see whether the need is widely shared.

[rprater]

I appreciate you laying this out for me @carljm. As you said, I do feel like "get my caller" is a common operation but probably not so common as to make it worthwhile to pollute the API with that extra function. I'll ensure I go to that link next time I have an idea.