Импорт насквозь

Потому что модуль попадает в sys.modules до исполнения своего тела — и вопрос только в том, успело ли выполниться нужное имя.

Когда a импортирует b, а b обратно a, второй импорт находит a в кеше и не запускает его заново — иначе была бы бесконечная рекурсия. Но тело a в этот момент выполнено лишь частично.

# a.py
X = 1
import b
Y = 2

# b.py
import a
print(a.X)      # → 1     эта строка уже выполнилась
print(a.Y)      # → AttributeError: partially initialized module

Отсюда всё наблюдаемое поведение: import a внутри цикла обычно работает (получаем объект модуля, обращаемся к атрибутам позже), а from a import Y — падает, потому что требует, чтобы Y уже существовал в момент импорта.

Как чинить, в порядке предпочтения. Первое — вынести общее в третий модуль: цикл обычно означает, что два модуля делят сущность, у которой нет своего места. Второе — импортировать внутри функции, а не на верхнем уровне: к моменту вызова оба модуля готовы. Третье — if TYPE_CHECKING, если импорт нужен только для аннотаций (урок 18).

Чего не делать: переставлять импорты местами до тех пор, пока не заработает. Это чинит симптом, и следующий человек, добавивший строку, сломает всё обратно.

Потому что from x import y создаёт отдельную привязку в импортирующем модуле, и подмена в исходном модуле её не касается.

# utils.py
def now(): return "настоящее время"

# report.py
from utils import now          # своя ссылка на объект функции
def make(): return f"отчёт: {now()}"

from unittest.mock import patch
import report

with patch("utils.now", return_value="ФЕЙК"):
    print(report.make())       # → отчёт: настоящее время   не сработало

with patch("report.now", return_value="ФЕЙК"):
    print(report.make())       # → отчёт: ФЕЙК              сработало

Причина прямо из механизма: from utils import now исполняется один раз при импорте report и записывает текущее значение в глобальные report. Дальше это две независимые записи в двух словарях, указывающие на один объект. Меняя одну, вторую не трогаешь.

А import utils + utils.now() ведёт себя иначе: там на каждом вызове читается атрибут модуля, и патч в utils виден.

Правило запоминается одной фразой: «патчь там, где ищут, а не там, где лежит». И именно поэтому mock.patch принимает строку, а не объект — по объекту невозможно понять, в чьём неймспейсе его подменять.

Потому что он делает невозможным ответ на вопрос «откуда взялось это имя», причём и для человека, и для инструментов.

Конкретные последствия, по убыванию вредности:

• Тихое затирание. Два таких импорта подряд — и второй молча перекрывает имена первого. Ошибка проявится далеко от места.
• Инструменты слепнут. Линтер не отличит опечатку от импортированного имени, IDE не найдёт определение, mypy теряет типы.
• Зависимость становится неявной. Из кода не видно, что именно используется, — значит нельзя ни сузить импорт, ни понять, что сломается при обновлении.
• Импортируется больше, чем видно. Без __all__ приезжают все публичные имена модуля, включая его собственные импорты.

# mod.py
import os, sys
PUBLIC = 1
_private = 2

# другой файл
from mod import *
print(PUBLIC, os)     # → 1 и модуль os приехал заодно

__all__ в модуле ограничивает список, но полагаться на чужую дисциплину не стоит.

Где приемлемо: в интерактивной сессии, где важна скорость набора; в __init__.py пакета, который сознательно переэкспортирует свой публичный API — и там обязательно с __all__; в конфигурационных модулях вроде settings_local, где перекрытие и есть цель. Во всём остальном коде — явный список имён.

Работают, но становятся другим типом пакета — с другим поведением, о котором обычно узнают в проде.

С 3.3 (PEP 420) каталог без __init__.py становится namespace package. Он задуман для одной задачи: разложить один логический пакет по нескольким местам на диске, чтобы company.tools и company.web ставились отдельными дистрибутивами.

Отличия, которые кусаются:

• Namespace-пакет собирается из всех подходящих каталогов на sys.path. Случайно совпавшее имя каталога где-то ещё — и содержимое пакета молча смешивается.
• Опечатка в имени не даёт ошибки импорта сразу. Пустой namespace-пакет импортируется успешно, а падает уже на обращении к подмодулю.
• Инструменты ведут себя по-разному. Часть сборщиков и find_packages() по умолчанию их не видит, и в колесо каталог не попадает.

import mypkg
print(mypkg.__path__)
# обычный пакет:   ['/путь/mypkg']
# namespace:       _NamespacePath(['/путь/mypkg', '/другой/путь/mypkg'])

Правило простое: если не строишь распределённый по дистрибутивам пакет — клади __init__.py, пустой. Он стоит ноль байт и делает поведение предсказуемым. Namespace-пакеты — специальный инструмент, а не «современный способ обойтись без файла».