Ответ.

Когда в Python происходит импорт модуля, интерпретатор ищет его в директориях, перечисленных в sys.path. Сначала ищет среди стандартных модулей, потом среди файлов .py, .pyc и каталогов с файлом __init__.py (пакеты).

1. Если модуль уже был импортирован, повторный импорт просто берёт его из sys.modules.
2. Если модуль не найден в стандартных путях, будет выброшено исключение ModuleNotFoundError.
3. При импортировании модуль транслируется в байт-код (.pyc) и кэшируется (если есть права на запись).

Пример:

# mypkg/__init__.py (может быть пустым)
# mypkg/mod.py
# main.py
import mypkg.mod

• Имя файла, структура каталогов, наличие/отсутствие __init__.py (для Python <3.3 обязательно) — всё имеет значение.

Как ищет:

• Сначала абсолютный импорт.
• Далее — поиск в директориях sys.path (первым всегда идёт директория текущего скрипта).
• В пакетах важен контекст (from . import ..., абсолютный/относительный импорт).

Вопрос с подвохом.

Что произойдёт, если в каталоге с вашим скриптом лежит файл с именем random.py и вы попытаетесь импортировать стандартный модуль random?

Ответ:

Импортируется МОЙ локальный файл random.py, а не стандартная библиотека. Частая причина трудновыявляемых багов — коллизия имён модулей с библиотечными (shadowing). Следует внимательно относиться к именованию файлов.

Примеры реальных ошибок из-за незнания тонкостей темы.

---

История

В большом проекте модуль email.py случайно затмил стандартный модуль email из библиотеки, и разработчики долго не могли понять, почему не работают функции парсинга почты из сторонних библиотек.

---

История

В ML-проекте функция os.path не работала: рядом с основным скриптом был файл os.py, который перехватывал все обращения к стандартному модулю. Месяц тратили на отладку, пока не нашли конфликт имён.

---

История

В микросервисном REST API возникли циклические импорты при попытке сделать относительный импорт моделей между несколькими подпакетами. Решили проблему только после рефакторинга структуры проекта и явного порядка загрузки модулей.