То, что inspect.getmodule(f) делает внутренне, для источников inspect.py , по сути sys.modules.get(object.__module__) - я бы не назвал использование этого кода напрямую "более удобным", хотя (помимо "по существу") часть, inspect имеет много полезных ловли и исправления угловых случаев).
Почему бы не позвонить напрямую inspect.getsourcefile (f) ?
Редактировать : читая между строк, кажется, что ОП пытается сделать что-то вроде
python /foo/bar/baz/bla.py
и внутри bla.py (который, таким образом, запускается как __main__) определяют «какой оператор from или import мог бы использовать другой основной скрипт для импорта этой функции из меня?».
Проблема в том, что вопрос некорректен, потому что любой такой путь не может быть использован для этой цели (ничто не гарантирует, что текущий путь основного сценария находится на sys.path, когда этот другой основной сценарий получает запустить позже), может быть несколько разных (например, /foo/bar и /foo/bar/baz могут быть на sys.path и /foo/bar/baz/__init__.py существуют, в этом случае from baz.bla import f и from bla import f могут оба работать), и ничто не гарантирует что какой-то другой , предыдущий элемент sys.path может не «упреждать» попытку импорта (например, скажем, /foo/bar/baz находится на sys.path, но перед ним также есть /fee/fie/foo и совершенно не связанный файл /fee/fie/foo/bla.py также существует - и т. Д. И т. П.).
Какой бы ни была цель такого рода попыток обнаружения, я предлагаю найти альтернативную архитектуру - например, такую, где from baz.bla import f фактически выполняется (как ОП говорит в начале вопроса), так что f.__module__ правильно установлено на baz.bla.