Краткий ответ

При циклическом импорте Python сначала создаёт объект модуля и помещает его в кэш sys.modules, а затем начинает выполнять его код. Если второй модуль в этот момент импортирует первый, он получает уже существующий, но ещё не полностью инициализированный модуль, поэтому нужное имя может отсутствовать.

Исторический контекст

Модульная система Python предназначена для разделения программы на независимые пространства имён и повторного использования кода. Чтобы один модуль не выполнялся заново при каждом импорте, интерпретатор использует кэш загруженных модулей.

Такой кэш решает проблему повторной инициализации, но создаёт особенность циклических зависимостей: запись модуля в кэш происходит до полного выполнения его тела. Это позволяет обнаруживать циклический импорт, однако открывает доступ к частично инициализированному объекту.

Постановка проблемы

Предположим, модуль a импортирует имя из b, а b импортирует имя из a. Во время выполнения a управление переходит к b; затем b обращается к a, который уже существует в sys.modules, но ещё не выполнил все объявления.

В результате возможны ошибки импорта или обращения к отсутствующему атрибуту. Проблема особенно часто возникает, когда модули импортируют конкретные имена через from ... import ..., потому что такое обращение немедленно требует наличия имени.

Подробное решение

Механизм импорта можно упростить до такой последовательности: найти загрузчик, создать объект модуля, поместить его в sys.modules, выполнить тело модуля и вернуть готовый объект. При цикле шаг выполнения одного модуля прерывается другим импортом, поэтому повторный импорт возвращает незавершённый объект, а не запускает модуль заново.

Например:

# a.py
from b import make_b

def make_a():
    return 'a'

# b.py
from a import make_a

def make_b():
    return 'b'

При загрузке a сначала начинает загружаться b. Модуль b пытается получить make_a из ещё не дошедшего до этого объявления модуля a, поэтому импорт может завершиться ошибкой о частично инициализированном модуле.

Импорт самого модуля через import a иногда позволяет отложить обращение к атрибуту до момента, когда оба модуля завершат инициализацию, но это не устраняет архитектурную зависимость автоматически. Надёжнее вынести общий контракт, типы или вспомогательные функции в третий модуль, изменить направление зависимостей или выполнять импорт внутри функции только как осознанный компромисс.

Локальный импорт может устранить ошибку и отложить загрузку, но ухудшает прозрачность зависимостей и способен скрыть архитектурную проблему. Разрыв цикла через отдельный модуль обычно делает структуру понятнее, хотя увеличивает число модулей и требует аккуратно определить их ответственность.

Ситуация из практики

В приложении модуль orders импортировал модели из users, а users импортировал функцию проверки заказа из orders. После добавления новой модели приложение перестало запускаться: при импорте возникала ошибка о недоступном имени в частично инициализированном модуле.

Рассматривались два варианта. Локальный импорт внутри функции быстро устранял цикл и почти не менял структуру, но сохранял связанность и делал порядок загрузки частью поведения программы. Вынесение общей проверки в модуль permissions потребовало перераспределить код, зато создало однонаправленные зависимости.

Выбран был второй вариант: users и orders стали зависеть от permissions, но не друг от друга. Приложение начало стабильно загружаться, а назначение каждого модуля стало яснее; дополнительным результатом стала возможность отдельно тестировать правила доступа.

Что кандидаты часто упускают

Вопрос: Почему добавление импорта внутри функции иногда устраняет циклическую зависимость?

Ответ: Такой импорт выполняется не при первоначальной загрузке модуля, а при вызове функции. К этому моменту исходные модули обычно уже завершили инициализацию, поэтому требуемое имя существует. Однако решение безопасно только если функция действительно не вызывается во время импорта и отложенная загрузка не создаёт нежелательных побочных эффектов.
Вопрос: Почему удаление модуля из sys.modules не является нормальным способом исправления цикла?

Ответ: Это вмешательство в внутреннее состояние импортной системы. Повторная загрузка может создать второй экземпляр глобального состояния, классов, регистраторов или настроек, а уже сохранённые ссылки продолжат указывать на старый объект. Такой приём допустим лишь в специальных сценариях вроде контролируемой перезагрузки, но не как архитектурное исправление.
Вопрос: Чем опасно считать успешный импорт гарантией полной готовности модуля?

Ответ: Для обычного завершившегося импорта это верно, но во время самого процесса импорта другой модуль может увидеть промежуточное состояние. Кроме того, код верхнего уровня модуля может выполнять регистрацию, чтение конфигурации или другие побочные действия, которые ещё не завершились. Поэтому публичные зависимости лучше формировать так, чтобы модуль не требовался другим модулям до окончания его инициализации.