Yeah, turns out we can't use__module__ reliably here, so I'm inclined to change it back and make it only return the module name (rather than encoding use of__globals__ on the caller's side).

I'd like a review from Mark, too.

The calling function is obtainable, even more easily than the module name. But in every case we already use this, we'd then have to go tofunc.__globals__['__name__'] and handle the cases where these are not consistent (__module__ is often<module> and not the actual module name).

If there's a use case for both, I'll happily add both, but right now, we don't need the function object for anything.

I'm thinking aloud here, so bear with me...

I don't think that_getframemodulename is a good name.
Not that_getframemodulename is a bad name for this API, maybe its just that the API is a bit odd?

It feels to me that this API is doing two things, getting the frame, then the module name. Why not split the parts?

frame = sys._getframe(n)modulename = get_module_name(frame)

or, potentially

modulename = sys._getframe(n).f_modulename

Unfortunately this doesn't achieve thestated goal of removing (almost) all uses ofsys._getframe(n)

Which leads us back toadding a function to get the caller function.
Functions already have a__module__ attribute, so we get

modulename = sys.getcallerfunc(n).__module__

Which seems cleaner to me.

@zooba You state in an earlier comment that__module__ is not reliable.
It seems to me that we should fix that, rather than working around the bug.

My cursory scan of the code suggests that__module__ == "<module>" only occurs in the repl, doctests and other source-less code.

Even in the repl, it seems that functtions have__module__ == "main".

@zooba You state in an earlier comment that__module__ is not reliable.
It seems to me that we should fix that, rather than working around the bug.

I didn't trace down exactly why it wasn't being filled in correctly, but I'm willing to bet it's a much more complicated compatibility issue to change it.__module__ is essentially a public API, while_getframemodulename is not.

It's definitely a bit of an odd API though, I agree. That's why I happily tried returning the function object instead. Perhaps it was only doctests that didn't set it correctly?

Also keen on your thoughts on theFRAME_OWNED_BY_CSTACK flagin this comment,@markshannon. I think I've used it right, but couldn't convince myself that this is the right way to skip frames.

You need to check for invalid frames when walking the frame stack.
You might want to factor out the walking the stack insys._getframe()https://github.com/python/cpython/blob/main/Python/sysmodule.c#L1889

OOI, what tests fail if you rely on__module__?

I've been looking into the__module__ issue, and it basically seems that<module> functions don't have__module__ set, which means anything at the top-level of a module won't work (e.g. virtually every typing, enum and dataclass definition). And this is the primary reason we use this, because anything that we'll be able to unpickle later on is going to have to be an importable name.

The only reliable workaround is to get it fromf_globals, as the code currently does. Tracing through the code, I think it's probably best to getfunc_module first if it's available, as that should let code assign tofunc.__module__ and override what gets returned. Then we can fall back tof_globals['__module__'] if it's not on the function object (yet) and still match.

I added a better test to compare_getframe with_getframemodulename and updated the check to match what is used in_getframe (which looks like a fairly different condition, but I trust you).

it basically seems that<module> functions don't have__module__ set

That sounds like a bug. Let's fix it rather than working around it.

Seems easy enough to fix, there's just a constructor that needs to pull__name__ out of globals.

Even so, I still don't see a reason why we'd return function objects. Our code either needs the module name, or else it needs actual frame information (e.g. current lineno). This is a private API, so if we need something different in the future we can always change it.

This is also why I made it not raise an error but returnNone, since everywhere we'd use it we would swap in a default value anyway (I was tempted to add adefault argument, but we'd want to replace explicitNone as well, so the semantics work better for us this way). We really never need the function object right now, at least not anywhere we don't also need the locals or lineno.

Even so, I still don't see a reason why we'd return function objects.

Two main reasons:

• It is a simpler, cleaner API. It makes introspecting the frame stack for profilers and the like (that don't care about the values of local variables) more efficient, and less of an auditing issue.
• Because we can. Until 3.11, we couldn't implement it. I suspect that if we could have, some of use cases that you describe would have used it before now.

My feeling is thatsys.getcallerfunc(n) wouldnot need an audit hook. Would you agree?
Or is that an argument in favor ofsys._getframemodulename()?

My feeling is that sys.getcallerfunc(n) would not need an audit hook. Would you agree?
Or is that an argument in favor of sys._getframemodulename()?

I started writing a reply earlier making the argument that only returning the name wouldn't require a red flag (I think it still deserves an event, but it's far less of a risk than if random code is unexpectedly doing_getframe). But I stopped because I don't actually have a strong argument, just a gut feel.

The most interesting thing you can do with a function object is mess withfunc_globals, which is the same assys.modules[sys._getframemodulename()] anyway, and dict lookups don't get an audit event (though possibly we could special casesys.modules if needed... I'd do that as my own patch first before trying to upstream it).

But because we don't use it, it means instead ofsys._getframemodulename() or 'default', we'd be writinggetattr(sys._getframefunction(), '__module__', None) or 'default' everywhere. That, plus YAGNI, is my argument for only returning the name (or None).

If there are no other concerns raised I'd like to merge this sometime this week.