Зачем нужны «ленивые» (lazy) импорты

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


Переносим import внутрь функции

Самый очевидный и безопасный способ сделать импорт ленивым — переместить import из глобальной области видимости внутрь функции или метода, где ресурс реально используется. При таком подходе импорт произойдёт только при первом вызове этой функции (и далее кешируется в sys.modules, поэтому реальной «повторной» загрузки не происходит). Это даёт быстрый выигрыш для модулей, которые редко используются или инициализируют тяжёлые зависимости:

def do_heavy_task():
    import heavy_lib
    heavy_lib.run()

Плюсы: простота. Минусы: если импорт нужен во многих местах, придётся либо дублировать import (что допустимо), либо устанавливать глобальную переменную после первого импорта.


Вариант с importlib — когда нужно контролировать пространство имён

Если хочется более явного контроля (например, избежать появления имени в локальной области каждой функции), можно использовать importlib.import_module() и присваивать результат в переменную (глобальную или локальную). Это зачастую полезно при динамическом импорте по имени строки:

Пример:

from importlib import import_module

def use_feature():
    mod = import_module("heavy_lib")
    mod.do()

Как найти «тяжёлые» импорты — инструмент `python -X importtime

Прежде чем делать импорты ленивыми, полезно понять, что именно тормозит загрузку. Для этого есть встроенная опция: python -X importtime your_program.py — она выводит дерево импорта с временами, позволяя увидеть самые затратные узлы. Это особенно полезно при оптимизации большого проекта или ускорении фазы сбора тестов.


Особая зона внимания — pytest и фаза collection

Pytest во время collection импортирует все тестовые файлы — следовательно, импорты в глобальной области тестов будут исполнены на этапе collection, даже если сам тест не будет запущен. Это распространённый источник задержек в больших тестовых наборах. Решение — переносить импорты внутрь тестовых функций, использовать importlib внутри тестов.


«Глобальный» трюк

Если модуль содержит множество функций, которые все используют одну и ту же тяжёлую библиотеку, имеет смысл импортировать её при первом нужном вызове и сохранить в глобальной переменной модуля (через `global`).
Короткая иллюстрация:

# module.py
heavy = None

def first_use():
    global heavy
    if heavy is None:
        import heavy_lib
        heavy = heavy_lib
    heavy.do()

Когда ленивые импорты — плохая идея

🔘 Если импорт жизненно важен для модуля и должен бросать ошибки во время старта (fail fast), откладывание импорта может скрыть проблему до момента выполнения, что усложнит отладку.
🔘 Когда импорт идёт с побочными эффектами, которые вы ожидаете увидеть при импортировании модуля — откладывая импорт, вы меняете поведение.

#основы
@zen_of_python

Дайте два 😮‍💨

Напомним, как всё было: летом вы голосовали за концепт и дизайн упаковки нашего фирменного напитка — между ТИПИЧНЫМ и ТОКСИЧНЫМ. Предсказуемо победил ТОКСИЧНЫЙ ПРОГРАММИСТ.

Лимитка получилась настолько удачной, что понадобился ещё один релиз. Paradox уже выкатили коллаб в продажу, а мы запускаем новый розыгрыш — 3 победителя получат коробку «ТОКСИЧНЫЙ ПРОГРАММИСТ» с шестью банками.

Подробнее с правилами можно ознакомиться здесь.

Чтобы участвовать, нужно:
— быть подписанным на @tproger и @paradox_beer;
— оставить реакцию под этим постом;
— нажать кнопку «Участвую».

Итоги подведём 27 октября. Победителей выберем с помощью бота.

А если ты не хочешь ждать, то можешь уже купить свой ТОКСИЧНЫЙ IPA. Всем удачи!

Участников: 709
Призовых мест: 3
Дата розыгрыша: 18:00, 27.10.2025 MSK (1 час)

super(): как это работает

Сегодня мы разберём одно из ключевых понятий объектно-ориентированного программирования в Python — super(). Когда мы работаем с наследованием, то порой сталкиваемся с дублированием кода:

class Employee:
    def __init__(self, name, salary):
        self.name = name
        self.salary = salary

    def raise_salary(self, amount):
        self.salary += amount


class Manager(Employee):
    def __init__(self, name, salary, department):
        self.name = name
        self.salary = salary
        self.department = department

На первый взгляд, всё верно. Но посмотрите внимательно — часть кода в Manager.__init__ дублирует логику базового класса Employee. В больших проектах уследить за всеми такими повторениями становится трудоемко. Решение простое — использовать super():

class Manager(Employee):
    def __init__(self, name, salary, department):
        super().__init__(name, salary)
        self.department = department

Теперь Manager вызывает конструктор базового класса Employee, а значит:

🔘 Код становится короче;
🔘 Меньше ошибок при рефакторинге.


Как это работает под капотом

Многие думают, что super() — это функция. На самом деле это класс. При его вызове возвращается прокси-объект, который даёт доступ к методам родительского класса. То есть строка:

super().__init__(name, salary)

означает:

«Возьми ближайший родительский класс в иерархии и вызови его метод `__init__()`».

Что важно помнить

🔘 super() работает не только в __init__. Его можно использовать в любых методах, которые переопределяются в подклассе;
🔘 Можно вызывать super() без аргументов — контекст определяется автоматически;
🔘 В сложных системах с множественным наследованием super() работает через механизм Method Resolution Order (MRO). Это гарантирует, что каждый базовый класс вызывается ровно один раз.

#основы
@zen_of_python