Python: вопросы для собеседования QA

List хранит порядок и допускает дубликаты, set хранит только уникальные значения без порядка.

Проверка вхождения (`in`) у set — O(1) за счёт хеш-таблицы, у list — O(n) линейный перебор.

Из практики: set использую для проверки уникальности идентификаторов в API-ответе — `assert len(ids) == len(set(ids))`. Список беру там, где важен порядок элементов.

Immutable объекты нельзя изменить «на месте» — вместо этого операция создаёт новое значение. Примеры: строки, кортежи, int, frozenset.

Это упрощает отладку и безопасно при конкурентном доступе — несколько потоков могут читать immutable объект без блокировок.

Из практики: строки как параметры тестовых фикстур — типичный immutable. Это страхует от случайного изменения тестовых данных при параллельном запуске.

Исключение прерывает обычный поток выполнения и передаёт управление в обработчик try/except (Python) или try/catch (Java).

Ловлю только ожидаемые, конкретные исключения — никогда не `except Exception` без крайней необходимости. Добавляю понятный контекст в сообщение об ошибке.

Из практики: в API-клиентах ловлю только `ConnectionError` и `Timeout`, а не все исключения — иначе тест проглатывает неожиданные ошибки и остаётся зелёным, когда должен упасть.

copy делает поверхностную копию: вложенные объекты остаются общими — оба объекта ссылаются на одни и те же вложенные структуры.

deepcopy копирует объект рекурсивно вместе со всеми вложенными структурами — полностью независимая копия.

Из практики: при создании тестовых данных через фабрику передаю deepcopy вложенных структур — иначе все тесты модифицируют один объект и падают случайным образом.

Параметризация в Pytest позволяет запускать один тест на наборе входных данных без копипаста.

Обычно использую `@pytest.mark.parametrize`, чтобы в отчёте видно было каждый набор данных как отдельный тест-кейс.

Из практики: параметризация быстро расширяет покрытие и делает регрессию компактнее.

Безусловный пропуск — декоратор `@pytest.mark.skip(reason="...")`; по условию — `@pytest.mark.skipif(condition, reason="...")` (например, версия Python, ОС, наличие зависимости).

Динамически внутри теста — вызов `pytest.skip("...")`, а `pytest.importorskip("module")` пропускает тест, если модуль не установлен.

Всегда указывай `reason`, чтобы в отчёте было видно: это ожидаемый пропуск или проблема.

Из практики: пропуск без причины быстро превращается в «тихую дыру» в покрытии.

Проверяю исключения через `pytest.raises`, чтобы явно зафиксировать ожидаемый тип ошибки.

Дополнительно сравниваю текст или атрибуты исключения, если важно подтвердить конкретный сценарий ошибки.

Из практики: такая проверка отлично ловит случаи, когда код падает «не тем» исключением.

Тип данных определяет множество допустимых значений и операций над ними.

В Python типы динамические: тип привязан к объекту, не к переменной. Одна переменная может указывать на объекты разных типов в разное время.

Из практики: динамическая типизация упрощает написание тестов, но без type hints легко передать строку туда, где ожидается int. Покрываю это аннотациями типов и mypy в pre-commit.

В Python часто используют числа, строки, булевы значения, списки, словари, множества и кортежи.

Важно понимать, какие типы изменяемые, а какие нет, чтобы избежать побочных эффектов в коде и тестах.

Из практики: большинство «странных» багов в Python-коде связано именно с изменяемостью объектов.

`==` сравнивает значения, а `is` проверяет, ссылаются ли переменные на один и тот же объект в памяти.

Для сравнения содержимого почти всегда нужен `==`, а `is` обычно применяю для `None` и диагностики ссылочной идентичности.

Из практики: путаница между `==` и `is` регулярно приводит к трудноуловимым багам в тестах.

В Python аргументы передаются как ссылки на объекты: функция работает с тем же объектом, который передали снаружи.

Если объект изменяемый, изменения внутри функции будут видны снаружи; если просто переприсвоить имя параметра, внешний объект не изменится.

Из практики: эту разницу важно помнить при работе со списками и словарями в тестовых фикстурах.

`*args` собирает произвольное число позиционных аргументов в кортеж, `**kwargs` — именованные аргументы в словарь.

Это удобно для гибких функций и обёрток, где заранее неизвестен полный набор параметров.

Из практики: в тестовых утилитах `**kwargs` помогает расширять API без ломающих изменений.

Список (list) — изменяемая последовательность, элементы можно добавлять, удалять, изменять. Кортеж (tuple) — неизменяемая последовательность: после создания элементы и длина фиксированы.

Кортеж чуть быстрее создаётся и занимает меньше памяти. Кортеж можно использовать как ключ словаря (если элементы хешируемы), список — нельзя.

Из практики: конфигурационные данные (URL-эндпоинты, ожидаемые статусы) храню в кортежах — случайное изменение в процессе параллельного выполнения тестов исключено.

Кортеж пригоден как ключ словаря, если содержит только хешируемые (неизменяемые) элементы — строки, числа, другие кортежи.

Если внутри кортежа есть список или словарь — он не хешируем и не может быть ключом; Python поднимет `TypeError: unhashable type`.

Из практики: комбинацию (user_role, feature_flag) использую как ключ словаря для кэширования ответов в параметризованных тестах — кортеж идеально подходит для составных ключей.

`lambda` — это короткая безымянная функция для простых случаев.

Я использую её, когда действие маленькое и код от этого становится короче и читабельнее.

Из практики: если логика сложная, лучше обычная функция с понятным именем.

Объектно-ориентированное программирование — парадигма, основанная на объектах, которые объединяют данные (атрибуты) и поведение (методы).

Четыре классических принципа ООП: инкапсуляция (скрытие внутреннего состояния), наследование (расширение классов), полиморфизм (единый интерфейс для разных типов) и абстракция (сокрытие деталей реализации за интерфейсом).

Из практики: в автотестах ООП помогает делать код модульным — Page Object использует инкапсуляцию, базовый класс теста — наследование, а паттерны Factory/Strategy — полиморфизм.

Итерируемый объект — это объект, по которому можно пройти в цикле, обычно через метод `__iter__`.

Итератор — объект, который возвращает элементы по одному через `__next__` и помнит текущее состояние обхода.

Из практики: понимание разницы помогает писать более экономичные проверки на больших наборах данных.

Группировка тестов в Pytest осуществляется через маркеры: `@pytest.mark.smoke`, `@pytest.mark.regression`, `@pytest.mark.slow`. Регистрируются в `pytest.ini` или `pyproject.toml`.

Запуск группы: `pytest -m smoke`, комбинации: `pytest -m 'smoke and not slow'`. Тесты также группируются физически — по файлам и по классам.

Из практики: разделяю тесты метками smoke, regression, integration — в CI запускаю только smoke на каждый коммит, полную регрессию ночью. Это сокращает цикл обратной связи с 40 до 5 минут.

С плагином pytest-xdist тесты запускаются параллельно в нескольких процессах: `pytest -n auto` (по числу ядер) или `pytest -n 4` (4 процесса).

Важно, чтобы тесты были независимы — общие данные без изоляции вызовут гонки и непредсказуемые падения. Каждый тест должен создавать уникальные данные.

Из практики: переход на pytest-xdist сократил время регрессии с 40 минут до 12. Главное условие — уникальные UUID в тестовых данных, чтобы тесты не конкурировали за одни записи.

Аннотации типов — синтаксис Python для указания ожидаемых типов переменных, параметров и возвращаемых значений: `def get_user(id: int) -> User:`.

Они не влияют на выполнение, но помогают статическим анализаторам (mypy) и IDE находить ошибки несоответствия типов до запуска кода.

Из практики: добавляю аннотации типов в API-клиенты и фабрики тестовых данных — mypy в pre-commit ловит ошибки типов раньше, чем они проявятся в CI.

Да, внутри кортежа могут быть изменяемые объекты. Неизменяемость кортежа означает, что ссылки на элементы фиксированы — нельзя заменить элемент на другой объект.

Но если элемент — изменяемый контейнер (список, словарь), его содержимое можно менять. Хешируемость кортежа при этом теряется.

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

Для поиска по ключу словарь значительно быстрее: в словаре это амортизированно O(1) за счёт хеш-таблицы, в списке — O(n) линейный перебор.

Список эффективнее при последовательном обходе всех элементов и индексированном доступе по позиции — там O(1). Для проверки вхождения (`in`) у set тоже O(1).

Из практики: если часто ищете по ключу — словарь или set; если важен порядок и доступ по индексу — список. Неправильный выбор структуры легко замедляет тесты на больших данных.

Срез списка в Python создаёт новый список, то есть выполняется копирование диапазона элементов.

Это поверхностная копия: вложенные изменяемые объекты не дублируются, копируются их ссылки.

Из практики: из-за этого часто появляются скрытые побочные эффекты в тестах с вложенными структурами.

Анонимные функции (lambda) оправданы когда функция очень простая, используется единовременно, и именовать её отдельно нет смысла.

Типичные применения: ключ сортировки `sorted(items, key=lambda x: x['price'])`, фильтрация `filter(lambda x: x > 0, values)`, простые callback в map/filter.

Из практики: если логика lambda требует более одного выражения — выношу в именованную функцию. Сложная lambda хуже читается, чем простая def с понятным именем.

Поверхностная копия (shallow copy) создаёт новый объект, но вложенные объекты не дублируются — копируются их ссылки. `copy.copy()` или `list[:]`.

Глубокая копия (deep copy) рекурсивно копирует все вложенные объекты, создавая полностью независимую структуру. `copy.deepcopy()`.

Из практики: при передаче тестовых fixture-объектов между тестами использую deepcopy — shallow copy однажды подвела: тест модифицировал вложенный список, ломая данные для следующего теста.

Функции высшего порядка — это функции, которые принимают другие функции или возвращают их.

Они полезны, когда нужно переиспользовать общий алгоритм и подставлять разное поведение через колбэки.

Из практики: такие функции часто упрощают фильтрацию и преобразование тестовых данных.

Big O описывает рост времени/памяти при увеличении входных данных. Основные классы: O(1) — константа, O(log n) — бинарный поиск, O(n) — линейный перебор, O(n log n) — сортировка, O(n²) — вложенные циклы.

Сложность операций в коллекциях Python: list — доступ O(1), поиск O(n), append O(1); dict — доступ/поиск/вставка O(1) амортизированно; set — проверка вхождения O(1); deque — append/pop с обоих концов O(1).

Из практики: понимание сложности помогает выбрать правильную структуру данных и не убить производительность тестов на больших наборах данных.

`super()` возвращает прокси-объект для вызова методов родительского класса. Используется внутри переопределённого метода для доступа к реализации родителя.

В Python 3 `super()` без аргументов автоматически определяет текущий класс. При множественном наследовании работает по MRO-цепочке.

Из практики: в базовом классе BasePage вызываю `super().__init__(driver)` — это гарантирует корректную инициализацию всей иерархии классов при множественном наследовании Page Object.

Декоратор — функция или класс, которые оборачивают другую функцию для расширения её функциональности без изменения исходного кода.

Синтаксис `@decorator` эквивалентен `func = decorator(func)`. Используются для: логирования, кэширования (lru_cache), контроля доступа, повторных попыток (retry), аннотаций Allure.

Из практики: пишу декоратор `@retry(times=3, delay=1)` для нестабильных сетевых шагов в API-тестах. Понимание механизма декораторов помогает разбирать фреймворки типа pytest и allure.

Абстрактный класс — класс с абстрактными методами, от которого нельзя создать экземпляр напрямую. В Python реализуется через ABC (Abstract Base Class): `from abc import ABC, abstractmethod`; подклассы обязаны реализовать все @abstractmethod.

В Python нет отдельного ключевого слова interface, но его роль выполняют ABC и Protocol (из typing). Protocol описывает структурный контракт (duck typing) — если объект имеет нужные методы, он соответствует Protocol без явного наследования.

Из практики: ABC использую когда нужно общее поведение и принудительный контракт для иерархии; Protocol — когда важна гибкость и не хочу привязывать сторонние классы к наследованию.

В Python есть соглашения по видимости: публичные, «защищённые» с одним подчёркиванием и «приватные» с двойным подчёркиванием.

Доступ к «приватным» атрибутам технически возможен через манглинг имени, поэтому это больше защита от случайного использования, чем жёсткий запрет.

Из практики: такие атрибуты трогаю только в крайних случаях, обычно лучше работать через публичный интерфейс класса.

Миксин — класс, предназначенный для «примешивания» поведения в другие классы через множественное наследование. Сам по себе не используется.

Обычно миксины предоставляют конкретные методы (логирование, сериализацию, валидацию) и не имеют собственного состояния (нет `__init__`).

Из практики: создаю `LoggingMixin` с методом `log_request()` и подмешиваю его в API-клиенты — все клиенты получают логирование без копипаста кода. Важно не злоупотреблять: глубокое множественное наследование сложно отлаживать.

Асинхронность позволяет задачам приостанавливать выполнение и уступать управление другим задачам, не блокируя поток. В Python реализована через asyncio и ключевые слова async/await.

Корутина — функция, объявленная через async def, которая может приостанавливаться в точках await, пока ожидает I/O или другую корутину. Event loop управляет переключением между корутинами.

Из практики: async/await особенно полезен при тестировании API и работе с WebSocket — позволяет запускать несколько запросов конкурентно без многопоточности.

Процесс — отдельная единица выполнения со своей памятью, регистрами и файловыми дескрипторами. Создаётся ОС и изолирован: крах одного не ронит другой. Поток (thread) существует внутри процесса, разделяет его память и ресурсы с другими потоками.

В CPython потоки ограничены GIL: реальный параллелизм возможен только при I/O-ожидании. Для CPU-параллелизма нужен multiprocessing. subprocess.Popen создаёт отдельный процесс с изолированной памятью.

Из практики: в pytest-xdist `-n auto` создаёт отдельные процессы, не потоки — именно поэтому обходит GIL и реально параллелит тесты на нескольких ядрах. При потоках такого выигрыша не получить из-за GIL.

Конкурентность (concurrency) — свойство программы быть способной работать над несколькими задачами одновременно: задачи могут переключаться, прогресс идёт у всех, но не обязательно одновременно. В Python реализуется через threading или asyncio.

Параллелизм (parallelism) — реальное одновременное выполнение нескольких задач в один момент времени, требует нескольких ядер. В Python достигается через multiprocessing, обходящий GIL.

Из практики: в тестировании API concurrency нужна для одновременной отправки запросов (asyncio или threading — достаточно, GIL снимается при I/O). Для параллельного запуска тестовых процессов применяю multiprocessing через pytest-xdist.

Многопоточность (multithreading) — несколько потоков выполнения в одном процессе, разделяющих общую память. В Python: модуль threading. Из-за GIL потоки не дают прироста на CPU-задачах, зато эффективны при I/O (сетевые запросы, файлы).

Многопроцессорность (multiprocessing) — несколько отдельных процессов с изолированной памятью. В Python: модуль multiprocessing. Позволяет обойти GIL и использовать несколько ядер для CPU-интенсивных задач.

Из практики: при нагрузочном тестировании API использую threading для конкурентных запросов — GIL снимается при ожидании сети. Для параллельного прогона тестов использую multiprocessing (pytest-xdist -n auto) — реальный прирост скорости на CI с несколькими ядрами.

Состояние гонки возникает, когда несколько потоков или процессов одновременно меняют общие данные без синхронизации.

Из-за этого результат может зависеть от случайного порядка выполнения и воспроизводиться нестабильно.

Из практики: такие дефекты лучше всего ловятся повторяемыми стресс-сценариями и подробным журналированием шагов.

Примитивы синхронизации координируют доступ нескольких потоков к общим ресурсам. Основные: Lock/RLock (взаимное исключение), Semaphore (ограничение числа одновременных потоков), Event (сигнал между потоками), Condition (ожидание условия).

RLock (реентерабельный) позволяет одному потоку захватить блокировку несколько раз. Barrier синхронизирует группу потоков в точке встречи. Queue из модуля queue — потокобезопасная очередь для передачи данных.

Из практики: в тестировании конкурентных сценариев использую Event для сигнализации между потоками и Queue для безопасной передачи результатов из фоновых задач.

Pydantic (v2): определяю `class User(BaseModel)` с аннотированными полями, валидация происходит автоматически при создании объекта. `model_validate(dict)` для парсинга, `model_dump()` для сериализации. `Field(...)` задаёт ограничения.

Marshmallow: схема наследуется от `Schema`, поля объявляются как атрибуты класса. `schema.load(data)` десериализует и валидирует, `schema.dump(obj)` сериализует. Более гибкий для кастомной логики.

Из практики: Pydantic v2 использую для валидации API-ответов в тестах — создаю модель ответа и `ResponseModel.model_validate(response.json())` сразу покажет расхождение с контрактом.

Сравниваю строку с её обратной версией после нормализации: приводим к нижнему регистру, удаляем пробелы и знаки препинания. Пример: `s = re.sub(r"[^a-zа-я0-9]", "", s.lower()); return s == s[::-1]`.

Покрываю крайние случаи: пустая строка (True), один символ (True), строка из пробелов/знаков (True после нормализации), строка с цифрами.

Из практики: на живом кодинге важно первым делом уточнить требования — учитывать пробелы и регистр или нет. После написания сразу показываю один-два теста на граничных значениях — это демонстрирует TDD-подход и внимание к краевым случаям.

Уточняю требования: по возрастанию/убыванию, стабильность сортировки, тип данных (числа, строки, объекты). В Python: `sorted(lst)` — новый список, `lst.sort()` — in-place. Для объектов: `sorted(items, key=lambda x: x["price"])`.

Стандартная сортировка Python (Timsort) — стабильная и O(n log n). Для убывания: `sorted(lst, reverse=True)` или `key=lambda x: -x["price"]`.

Из практики: на живом кодинге сначала пишу базовый случай, потом добавляю edge cases в тестах: пустой список, один элемент, список с дублями, список с None. Вопрос «а что делать с None?» — хорошая точка для демонстрации инженерного мышления.

Пишу минимально рабочий тест: подготовка данных (если нужна), отправка запроса через requests или httpx, проверка status code и ключевых полей тела ответа. Пример: `response = requests.post(url, json=payload, headers={"Authorization": token}); assert response.status_code == 201; assert response.json()["id"] is not None`.

Добавляю негативный кейс: неверные данные → 400 с понятным сообщением. Без авторизации → 401. Если применимо — проверяю состояние в БД через отдельный GET-запрос.

Из практики: хороший API-тест виден как тест, а не как скрипт. Явные assert с сообщением, понятные имена переменных и строгий teardown — по ним сразу видно уровень кандидата на живом кодинге.

Пишу фикстуру с явным setup и teardown через yield: всё до yield — подготовка, после — очистка. Выбираю scope осознанно: `function` для изолированных тестов, `session` для дорогих ресурсов типа токена авторизации или Docker-контейнера.

Важно: teardown должен выполняться даже при падении теста. Паттерн с yield гарантирует это в отличие от addfinalizer.

Из практики: на живом кодинге показываю фикстуру с yield, объясняю разницу scope и демонстрирую autouse=True как отдельный инструмент. Сразу проговариваю: если teardown не чистит данные надёжно — это источник флаки при параллельном запуске.

Фикстура в Pytest готовит и при необходимости очищает окружение для теста.

Она уменьшает дублирование в тестах и делает подготовку данных единообразной.

Из практики: правильно оформленные фикстуры заметно повышают стабильность тестового набора.

Scope определяет, как часто фикстура создаётся: function (по умолчанию) — новая для каждого теста, полная изоляция; class — одна на все тесты класса; module — одна на весь файл; session — одна на весь прогон.

Более широкий scope ускоряет тесты (меньше создания/удаления), но снижает изоляцию. Фикстура с session-scope должна быть потокобезопасной при параллельном запуске.

Из практики: использую function для данных, class для логически связанных тестов, module/session для тяжёлых ресурсов — БД-соединения, Docker-контейнеры. Неверный scope — самая частая причина флаки-тестов.

Да, для этого у фикстуры выставляется параметр `autouse=True`. Фикстура применяется ко всем тестам в области видимости (файл или весь проект при размещении в `conftest.py`) без явного указания в параметрах теста.

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

Из практики: осторожно с autouse в широком scope — она работает для всех тестов файла или проекта, в том числе там, где не нужна. Предпочитаю явную передачу фикстуры, чтобы зависимости теста были видны в его сигнатуре. autouse применяю только для инфраструктурных вещей типа очистки БД или сессии логирования.

Часто используемые встроенные фикстуры: tmp_path — временная директория (Path-объект), уникальная для каждого теста; capfd / capsys — перехват вывода в stdout/stderr; monkeypatch — патчинг атрибутов, переменных окружения, функций.

Также: request — доступ к метаданным теста и параметрам; pytestconfig — доступ к конфигурации запуска; mocker — из плагина pytest-mock, удобная обёртка над unittest.mock.

Из практики: monkeypatch незаменим для тестирования кода, зависящего от env-переменных или системного времени — патчу нужные значения без правки кода.

Генератор — это функция, которая возвращает значения по одному через `yield`, а не строит всё сразу в памяти.

Он полезен для больших наборов данных и потоковой обработки, где важна экономия памяти.

Из практики: генераторы часто спасают тесты от лишнего потребления памяти на больших фикстурах.

GIL (Global Interpreter Lock) — мьютекс в CPython, который позволяет исполнять байт-код только одному потоку одновременно. Упрощает управление памятью и делает отдельные операции потокобезопасными без явных блокировок.

Главный недостаток: GIL не позволяет Python-потокам реально параллельно выполнять CPU-интенсивный код на нескольких ядрах. Для CPU-параллелизма нужен multiprocessing. Для I/O-задач GIL практически не мешает, так как снимается при ожидании.

Из практики: при параллельном запуске тестов использую pytest-xdist с multiprocessing (-n auto) — это обходит GIL и реально ускоряет прогон на многоядерных машинах.

Паттерн проектирования — типовое решение часто встречающейся архитектурной задачи. Классифицируются по GoF: порождающие (Builder, Factory, Singleton), структурные (Adapter, Decorator, Proxy), поведенческие (Strategy, Observer, Command).

В Python паттерны часто реализуются проще, чем в Java, за счёт duck typing, декораторов и функций первого класса.

Из практики: в тестовых проектах Builder использую для создания сложных объектов данных, Strategy — для разных стратегий авторизации, Observer — для тестовых слушателей событий в Allure.

Метакласс управляет тем, как создаются классы в Python.

Нужен редко: обычно для инфраструктурных задач, где надо централизованно проверять или изменять классы при создании.

Из практики: в обычном прикладном коде метаклассы чаще усложняют поддержку, чем помогают.

Diamond problem — проблема ромбовидного наследования: когда класс D наследует от B и C, оба из которых наследуют от A — возникает неопределённость, какой метод A вызвать.

MRO (Method Resolution Order) — порядок поиска методов. Python использует алгоритм C3-линеаризации: порядок всегда предсказуем и можно проверить через `ClassName.__mro__`.

Из практики: при построении иерархии Page Object с миксинами важно вызывать `super()` в каждом классе цепочки — это гарантирует, что MRO отработает корректно и ни один `__init__` не будет пропущен.

Список (list) — изменяемая упорядоченная коллекция. Кортеж (tuple) — неизменяемая. Поэтому tuple можно использовать как ключ словаря и элемент множества, а list — нет.

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

Из практики: возвращайте кортеж, когда функция отдаёт несколько разнотипных значений. Используйте list для коллекции, которая может расти.

List comprehension — это компактный синтаксис для создания списка из итерируемого: [x*2 for x in range(10) if x % 2 == 0].

Преимущества: короче и часто быстрее, чем явный цикл с .append(). Бывают аналоги для словарей ({k: v for ...}) и множеств ({x for ...}). Для генераторов — круглые скобки.

Из практики: для одного-двух преобразований comprehension читабелен. Для сложной логики лучше явный цикл или функция.

GIL (Global Interpreter Lock) — это мьютекс в CPython, позволяющий только одному потоку выполнять Python-байткод в каждый момент. Память управляется без гонок.

Следствие: настоящий многопоточный CPU-bound параллелизм невозможен. Для IO-bound потоки помогают, потому что GIL отпускается на время блокирующих операций.

Из практики: CPU-bound задачи распараллеливают через multiprocessing (отдельные процессы) или asyncio (для IO). Также Cython, NumPy, multiprocessing.Pool обходят GIL по-разному.

asyncio — это однопоточная кооперативная многозадачность через event loop. Корутины (async/await) приостанавливаются в точках await, давая работать другим.

threading — потоки ОС. В CPython упираются в GIL для CPU-bound, но дают параллелизм для IO-bound (через release GIL).

Из практики: для IO-bound (тысячи параллельных HTTP-запросов) asyncio эффективнее. Threading удобен, когда нужно работать с блокирующими библиотеками.

Context manager — это объект, реализующий __enter__ и __exit__ (или async-варианты). Используется с with: с гарантией, что __exit__ вызовется, даже при исключении.

Стандартное применение: открытие файлов, соединений с БД, lock'ов, transactions. with open('f') as f: гарантирует закрытие файла.

Из практики: декоратор contextlib.contextmanager упрощает создание собственных менеджеров. Это лучший способ управлять ресурсами в Python.

Декоратор — это функция (или класс), которая принимает функцию и возвращает новую функцию, обычно расширяющую поведение оригинала: логирование, проверка прав, кеширование.

Синтаксис @decorator над определением — это сахар над function = decorator(function). Поддерживает параметры через ещё один уровень вложенности.

Из практики: широко используется в Django, Flask, FastAPI, pytest (фикстуры, параметризация). Свои декораторы пишут для cross-cutting concerns.

Генератор — функция, в которой есть yield. При вызове она возвращает iterator-объект. На каждом __next__ выполнение идёт до следующего yield, отдаёт значение, замораживает состояние.

Также есть generator expression — компактный синтаксис: (x*2 for x in range(10)). Не создаёт список целиком, экономит память.

Из практики: незаменимо для обработки больших данных — построчное чтение файлов, потоковая обработка, пайплайны. lazy-семантика снижает потребление памяти.

Type hints — аннотации типов: def add(x: int, y: int) -> int. Сам Python не проверяет их в рантайме, но IDE и mypy/pyright дают подсказки и проверку статически.

Сильно повышают читаемость и снижают число багов на больших проектах. Поддерживаются Generic, TypedDict, Protocol, Literal, Union, Optional.

Из практики: для production-кода стоит включить mypy в CI. Полная типизация даёт уверенность при рефакторингах.

pickle — формат сериализации объектов Python в байты. Сохраняет почти любой объект, в т.ч. свои классы.

Опасность: десериализация pickle из недоверенного источника = удалённое выполнение кода. Pickle позволяет вызвать произвольный код при загрузке.

Из практики: используйте pickle только внутри своего процесса для своих данных. Для обмена с внешним миром — JSON, MessagePack, Protobuf.

Virtual environment — изолированная директория с собственным Python и своим набором пакетов. Не пересекается с системным Python и другими проектами.

Создают через python -m venv .venv. Активируют source .venv/bin/activate. Все pip install ставят в эту среду.

Из практики: всегда работайте в venv. Альтернативы — poetry, pipenv, uv. Это убирает конфликты версий между проектами и облегчает развёртывание.

Методы с двойным подчёркиванием: __init__ (инициализация), __str__ (строковое представление), __eq__ (равенство), __hash__, __iter__, __len__, __add__ и др.

Они определяют, как объект ведёт себя со встроенными операциями (print, ==, in, len, +).

Из практики: реализуя dunder-методы, делают свои классы pythonic — они интегрируются со стандартным языком, как встроенные.

MRO (Method Resolution Order) — порядок, в котором Python ищет методы при множественном наследовании. Алгоритм C3 linearization даёт детерминированный порядок.

Diamond problem — когда A наследуется от B и C, оба — от D. Без правильного MRO непонятно, чей метод вызвать. C3 даёт ответ и super() работает корректно.

Из практики: смотрят через ClassName.__mro__ или mro(). Понимание MRO критично, когда строите сложные иерархии с миксинами.

@dataclass — декоратор, генерирующий __init__, __repr__, __eq__ для класса с типизированными полями. Доступен с Python 3.7.

Похоже на data class в Kotlin или record в Java. Поддерживает frozen=True (иммутабельность), default, default_factory.

Из практики: для DTO, конфигов, value-объектов. Резко уменьшает шаблонный код. Для строгой валидации — pydantic, но dataclass быстрее на стандартных задачах.

requests — самая популярная библиотека для HTTP-запросов в Python: requests.get, .post, .put и т.д. Простой интерфейс, JSON-парсинг, поддержка сессий.

Альтернативы: httpx (поддерживает async, drop-in replacement), aiohttp (для asyncio), urllib3 (низкоуровневая основа).

Из практики: для скриптов и тестов — requests. Для async-приложений (FastAPI и др.) — httpx. requests разрабатывается медленно, но остаётся стандартом.

pytest — самый популярный фреймворк тестирования в Python. Простой синтаксис (обычные функции с assert вместо self.assertEqual), мощные фикстуры, параметризация, плагины.

В сравнении с unittest: меньше boilerplate, лучшие сообщения об ошибках (assert rewriting), огромная экосистема плагинов (pytest-asyncio, pytest-cov, pytest-xdist).

Из практики: для нового проекта почти всегда pytest. unittest остаётся, если уже есть много тестов или нужна совместимость со старыми инструментами.

Фикстура — функция с @pytest.fixture, готовящая ресурсы и/или данные для тестов. Тест получает её как аргумент по имени.

Поддерживает scope (function, class, module, session) — как часто пересоздавать. Также есть autouse и параметризованные фикстуры.

Из практики: фикстуры в conftest.py доступны всем тестам в директории. Удобно для общих setup'ов: подключение к БД, тестовый клиент, авторизованный пользователь.

@pytest.mark.parametrize('input,expected', [(1, 2), (3, 6), (4, 8)]) — тест выполнится трижды с разными значениями. Имена параметров — аргументы функции.

Можно использовать ids=[...] для понятных имён в отчёте. Параметризовать можно и фикстуры через params=[...].

Из практики: незаменимо для data-driven тестов: одна логика, много кейсов. Куда лучше, чем копировать тесты.

Маркер — это тег на тесте через @pytest.mark.<name>. Встроенные: skip, skipif, xfail, parametrize. Свои — для категоризации (smoke, slow, regression).

Запуск по маркеру: pytest -m smoke. Можно комбинировать: -m 'smoke and not slow'.

Из практики: помогает разделять наборы — smoke в PR, регрессия — в ночном прогоне. Регистрировать кастомные маркеры в pyproject.toml/pytest.ini, иначе будут warning.

conftest.py — специальный файл, содержащий общие фикстуры, хуки, плагины для тестов в его директории и поддиректориях.

Pytest ищет conftest.py автоматически. Можно иметь несколько на разных уровнях — пересечение фикстур разрешается по близости.

Из практики: в нём — фикстуры clients, моки, общие хуки (pytest_runtest_setup и др.). Не нужно импортировать — pytest подхватит.

Плагин pytest-xdist распараллеливает тесты на несколько процессов: pytest -n 4 — 4 параллельно. Также поддерживает запуск на нескольких машинах.

Тесты должны быть изолированными — иначе гонки в общих данных/фикстурах.

Из практики: даёт почти линейное ускорение, если тесты независимы. Распределение — по тестам, по группам, по модулям.

Плагин для тестирования asyncio-кода. С помощью @pytest.mark.asyncio (или mode=auto) можно писать async def test_...().

Также поддерживает асинхронные фикстуры. Хорошо сочетается с httpx, aiohttp, FastAPI.

Из практики: для проектов с asyncio плагин обязателен. Версии не всегда обратно совместимы — фиксируйте в зависимостях.

pytest-cov собирает покрытие кода тестами (через coverage.py). Запуск: pytest --cov=src --cov-report=html. Видно, какие строки/ветви выполнились.

Можно задавать порог: --cov-fail-under=80 — упасть, если покрытие ниже 80%.

Из практики: покрытие — индикатор, а не цель. 100% не значит «всё проверено», 60% не значит «всё плохо». Полезно как ограждение от регрессии.

monkeypatch — встроенная фикстура pytest для подмены: атрибутов, переменных окружения, времени. Все изменения откатываются автоматически после теста.

pytest-mock даёт фикстуру mocker — обёртку над unittest.mock.patch, тоже с автоочисткой после теста.

Из практики: для подмены глобальных штук, чистых функций — monkeypatch. Для проверки вызовов (assert_called_with) — mocker (через MagicMock).

pytest_runtest_setup/teardown — до/после каждого теста. pytest_collection_modifyitems — изменить набор тестов (фильтр, переупорядочить). pytest_addoption — добавить свои CLI-флаги. pytest_html_results_table_row — кастомизировать HTML-отчёт.

Хуки регистрируются в conftest.py.

Из практики: pytest_addoption + фикстура — типовой способ добавить параметры окружения (--env, --browser). modifyitems — для умного skip.

Оператор := (Python 3.8+) присваивает значение в выражении. Удобно в while/if: while (chunk := file.read(1024)): process(chunk).

Избавляет от дублирования вычисления переменной.

Из практики: полезно для list comprehension с условием, обработки потоков, чтения данных частями.

pathlib предоставляет объектно-ориентированный API для путей: Path('foo') / 'bar' дает Path('foo/bar'). Методы read_text, write_text, glob, mkdir.

По сравнению с os.path — куда проще и кросс-платформенно, без ручной работы со строками.

Из практики: для нового кода — pathlib. os.path остаётся в legacy и в местах с особой производительностью.

f-string — синтаксис для интерполяции: f"Hello, {name}!". Поддерживает выражения, форматирование, методы.

Быстрее, чем % и .format(). С Python 3.8 — также f"{value=}" для отладки (выводит имя и значение).

Из практики: для нового кода почти всегда f-strings. Кратко, читаемо, эффективно.

@property превращает метод класса в атрибут — обращение без скобок. Также есть .setter и .deleter для записи/удаления.

Удобно для вычисляемых свойств с возможной валидацией: temperature_in_fahrenheit зависит от celsius.

Из практики: используют для инкапсуляции — пользователь работает как с полем, реализация может быть вычислением. Не делайте тяжёлые вычисления в property без явных намёков.

__new__ создаёт экземпляр (вызывается до __init__) и возвращает его. __init__ инициализирует уже созданный объект.

Обычно переопределяют только __init__. __new__ — когда нужно контролировать создание (singleton, кэширование, immutable классы).

Из практики: для большинства задач хватает __init__. __new__ — продвинутая тема, и часто признак переусложнения.

По умолчанию присваивание в функции создаёт локальную переменную. global делает её ссылкой на модульную переменную. nonlocal — на переменную в окружающей функции (для замыканий).

Без global/nonlocal присваивание создаст новую локальную, скрывая внешнюю.

Из практики: использование global — обычно признак плохого дизайна. nonlocal иногда нужен в замыканиях. Чаще лучше передавать значения через параметры.

logging — стандартный модуль с уровнями (DEBUG, INFO, WARNING, ERROR, CRITICAL), форматтерами, хендлерами (файл, stdout, syslog).

print не имеет уровней, форматирования, и направляется только в stdout. В продакшене не контролируется.

Из практики: для серьёзного приложения настраивайте logging с самого начала. JSON-формат для structured logging, чтобы потом удобно искать в Elasticsearch/Loki.

requirements.txt — простой файл со списком пакетов и версий. pip install -r установит. Не разделяет dev и runtime, нет lock-файла.

Poetry — современный менеджер: pyproject.toml + poetry.lock, разделение групп зависимостей, виртуальное окружение, публикация. uv — ещё новее и быстрее.

Из практики: для новых проектов Poetry или uv. requirements.txt — для простых скриптов и обратной совместимости.

match — pattern matching: match value: case 1: ...; case [a, b]: ...; case Point(x=0): .... Гораздо мощнее обычного switch — деструктуризация, охрана условиями, типы.

В отличие от if/elif цепочки, match читается яснее и компилятор может проверить exhaustiveness в типизированном коде.

Из практики: для разбора ADT-подобных структур (Result, Either) match — идеальный инструмент.

__slots__ = ('x', 'y') — список разрешённых атрибутов класса. Без него Python хранит атрибуты в __dict__ (более гибко, но больше памяти).

Преимущества: меньше памяти, быстрее доступ, нельзя добавить новый атрибут случайно.

Из практики: применяют для классов, которых много (миллионы экземпляров). Для обычных классов overhead не критичен.

Конфигурация pytest хранится в pyproject.toml ([tool.pytest.ini_options]), pytest.ini или setup.cfg. Указывают: testpaths, python_files, markers, фильтр warnings, опции.

Также флаги по умолчанию через addopts: --strict-markers --tb=short.

Из практики: важно настроить markers, чтобы избавиться от warning. И testpaths, чтобы pytest искал тесты только в нужных директориях.

@pytest.mark.xfail помечает тест как «ожидаемо падающий». Если он падает — тест зелёный (xfailed). Если внезапно проходит — XPASS (это сигнал что-то изменилось).

Часто применяют для известных багов до их фикса — тест отмечает регрессию, но не валит CI.

Из практики: xfail полезен временно. Долго существующий xfail — признак, что баг забыт.

Плагины — расширения pytest. Самые ходовые: pytest-asyncio, pytest-cov (покрытие), pytest-xdist (параллелизация), pytest-mock, pytest-django, pytest-html, pytest-bdd.

Подключаются установкой пакета — pytest автоматически их подхватывает.

Из практики: для каждого проекта набор плагинов формируется быстро. Стоит выбирать активно поддерживаемые.

with pytest.raises(ValueError): code_that_should_raise() — проверяет, что код бросает исключение указанного типа.

Можно проверить сообщение: pytest.raises(ValueError, match="invalid").

Из практики: каноничный способ проверить, что исключение брошено. Если код не бросил — тест упадёт.

По умолчанию pytest захватывает stdout/stderr тестов и показывает только при падении. Фикстура capsys даёт доступ к захваченному выводу.

Опции: -s отключает захват (всё печатается в реальном времени), --capture=no — то же.

Из практики: capsys полезен для тестирования CLI-инструментов и логирования. -s — для отладки.

tmp_path — встроенная фикстура pytest, возвращающая уникальный Path для каждого теста. Автоматически очищается.

Удобно для тестов, работающих с файлами: создаёте файлы в tmp_path, проверяете, не беспокоитесь о cleanup.

Из практики: всегда используйте tmp_path вместо вручную создаваемых /tmp/test_X — изоляция и автоматическая чистка.

@pytest.mark.skipif(condition, reason='...') пропускает тест при истинном условии. Часто используют для платформо-зависимых: skipif(sys.platform == 'win32', reason='Unix only').

Также есть встроенные: @skipif(not os.getenv('DB_URL'), reason='no db').

Из практики: типовое применение — тесты, требующие специфичных ресурсов или версий.

Фикстура, возвращающая функцию-фабрику, а не сам объект. Тест вызывает её несколько раз с разными параметрами: user1 = make_user(name='A'), user2 = make_user(name='B').

Часто комбинируется с подсчётом и очисткой созданных сущностей.

Из практики: незаменимо, когда в тесте нужно несколько похожих объектов с вариациями.

Плагин для BDD-стиля: feature-файлы в Gherkin (Given/When/Then), step-определения в Python. Запускается через обычный pytest.

Альтернатива behave с такой же идеей, но интегрированная с pytest и его экосистемой.

Из практики: для команд, где QA пишет сценарии в Gherkin, а разработчики — степы. Минусы: дополнительный слой абстракции, не всегда оправдан.

Плагин для тестирования Django-приложений. Даёт фикстуры db (общая БД), client (Django test client), live_server, settings и т.д.

Также интегрирует pytest с Django: миграции, transactions, фабрики.

Из практики: для Django-проектов — почти стандарт. Заменяет встроенный django.test и даёт удобства pytest.