Получите функциональный путь импорта
from pack.mod import f
Как получить от объекта f информацию об импорте - 'pack.mod'
Я могу получить его использование f.__module__ но если функциональное определение в модуле, где я получаю этот атрибут (f.__module__) это возвращается '__main__'. Но мне нужен реальный путь здесь - 'pack.mod'
Я нашел этот способ получить эту информацию:
inspect.getmodule(f).__file__
затем я могу sub запускать путь с sys.path, замена / на . и получите путь как - 'pack.mod' Но может быть, существуют некоторый более удобный способ?
1 ответ
То, что inspect.getmodule (f) делает внутренне, согласно источникам inspect.py , по сути, является sys.modules.get (object .__ module __) - - Я бы не назвал использование этого кода напрямую «более удобным» (помимо части «по существу» inspect содержит много полезных функций для выявления и исправления угловых случаев).
Почему бы не вызвать напрямую inspect.getsourcefile (f) ?
Изменить : чтение между строками кажется, что OP пытается сделать что-то вроде
python /foo/bar/baz/bla.py
и внутри bla.py (который, таким образом, выполняется как __ main __ ) определяет, «какой оператор из или import может использовать другой основной скрипт для импорта этой функции изнутри меня? ».
Проблема в том, что вопрос сформулирован некорректно, потому что может не быть какого-либо такого пути, который можно было бы использовать для этой цели (ничто не гарантирует, что текущий путь основного сценария находится на sys.path когда этот другой основной сценарий запускается позже), может быть несколько разных сценариев (например, оба / foo / bar и / foo / bar / baz могут быть в sys. path и / foo / bar / baz / __ init __. py существуют, и в этом случае из baz.bla import f и из bla import f могут оба работают), и ничто не гарантирует, что некоторые другие , предыдущие sys.path элемент могут не «вытеснить» попытку импорта (например, скажем / foo / bar / baz находится в sys.путь , но перед ним есть также / fee / fie / foo , а также существует совершенно не связанный файл /fee/fie/foo/bla.py и т. д., так далее).
Какой бы ни была цель такого рода попытки обнаружения, я предлагаю найти альтернативную архитектуру - например, ту, где из baz.bla import f выполняется на самом деле (как сказано в OP на начало вопроса), так что f .__ module __ правильно установлен на baz.bla .