Note that a lot of refactoring happened in the test suite to enable testing this behavior. The history of the refactoring can be found in python/importlib_resources@f77da58...23afc90. These changes were released with importlib_resources 6.4.1.

I'm a little apprehensive about the prospect of backporting this to Python 3.12, given the amount of refactoring that had to happen in the tests to make them viable. I may opt to backport the fix but limit the amount of changes backported to the tests, depending on how complicated it turns out to be.

@Gatsik - the implementation provided herein has already been reviewed and released as importlib_resources 6.4.1. It proves the fix and is available.

The one thing that it misses is that it doesn't fix the issue when the importlib library itself is compiled -- in that case inferring caller doesn't work correctly (my attempt to fix it: Gatsik@50c1596)

It's not obvious to me from this fix what the failure mode is. I think I see it now - if the _common module is available as bytecode but has no source, then __file__ may not be valid. I think that issue would affect both zip files and direct disk files. Would you be willing to write up a separate issue, either in this repo or in python/importlib_resources that describes the missed expectation and why it's an important use-case to support? It's certainly something worthy of consideration, but it's also something that can be considered independent of this PR.

@jaraco sure! i created an issue #123085

Thanks @jaraco for the PR 🌮🎉.. I'm working now to backport this PR to: 3.12, 3.13.
🐍🍒⛏🤖

Sorry, @jaraco, I could not cleanly backport this to 3.12 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker ba687d9481c04fd160795ff8d8568f5c9f877128 3.12

GH-123986 is a backport of this pull request to the 3.13 branch.