Разработка и применение программного обеспечения в физических исследованиях

Вячеслав Федоров, ИЯФ СО РАН

Учебное пособие для студентов второго курса, обучающихся по направлению «Прикладная математика и физика».

Предмет книги

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

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

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

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

Предполагается, что читатель знаком с основами программирования и с математическим аппаратом первого курса, то есть с анализом и линейной алгеброй. Всё остальное рассматривается по ходу изложения.

Результаты изучения пособия

В результате изучения пособия студент должен уметь:

• Пользоваться ИИ-помощниками и контролем версий. Языковые модели с пониманием того, где они помогают, а где вредят; Git как рабочий инструмент.
• Работать в GNU/Linux. Устройство системы, файловые системы, процесс загрузки, инструменты командной строки и диагностика неполадок: без этого минимума работа на вычислительном кластере невозможна.
• Владеть Python. Устройство объектов и коллекций, функции, декораторы, классы, генераторы и цена, скрытая за каждой операцией.
• Понимать алгоритмы и структуры данных. Это позволяет оценивать, справится ли расчёт с заданным объёмом данных, и выбирать подходящую структуру.
• Применять инженерные практики. Жизненный цикл программы, тестирование, превращение скрипта, написанного за вечер, в приложение, поддерживаемое годами, сети и базы данных.
• Обрабатывать и анализировать данные. NumPy, pandas, визуализация, классические алгоритмы машинного обучения и нейронные сети.
• Ускорять программы. Профилирование, многопоточность и GIL, асинхронность, вычисления на графических ускорителях.
• Читать чужой код. Разбор реальных программ, с помощью которых выполняются физические расчёты в институтах СО РАН, и одного веб-сервиса, взятого без физики, чтобы за ней не скрывалась архитектура, — вместе с заложенными в них компромиссами и с решениями, которые сегодня были бы приняты иначе.

Структура книги

Порядок частей продиктован зависимостями между ними.

Сначала рассматриваются инструменты: помощники на языковых моделях и контроль версий. Затем операционная система, от загрузки до устройства ядра, и контейнеры, основанные на его механизмах. Далее сам язык, его объекты, коллекции и классы, а следом алгоритмы и структуры данных, примеры для которых на этом языке и написаны. Инженерные практики идут после: жизненный цикл программы, требования к коду, сети, базы данных. Завершается пособие работой с данными эксперимента, ускорением расчётов, разбором реальных программ, написанных в институтах СО РАН, и заданиями для самостоятельной работы.

Читать пособие рекомендуется последовательно, поскольку главы опираются друг на друга. Если какая-либо тема требуется немедленно, достаточно воспользоваться оглавлением и перекрёстными ссылками.

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

Интерпретация замеров времени

В пособии приведено много измерений вида «эта версия быстрее в сто раз» или «на миллионе элементов уходит две секунды».

Рассматривать следует отношения, а не секунды. Абсолютное время ничего не значит без указания машины, на которой оно получено: тот же код на ноутбуке пятилетней давности и на серверном процессоре даёт числа, отличающиеся в разы. Утверждение «Numba ускоряет этот цикл в сто раз» от процессора не зависит, а утверждение «эта функция считается 14 секунд» зависит. Все выводы в пособии построены на отношениях, и именно их целесообразно проверять, запуская код на собственной машине.

Одно и то же измерение, повторённое подряд, даёт разные числа, поскольку на результат влияют кеш процессора, сборщик мусора, фоновые процессы и троттлинг, снижающий частоту при нагреве. Поэтому замер повторяется многократно: %timeit в IPython показывает среднее и стандартное отклонение по семи прогонам, а timeit.repeat из стандартной библиотеки возвращает серию замеров, из которой берётся минимум. Единичного замера недостаточно: если два варианта различаются на десять процентов, а разброс составляет двадцать, измерение не даёт никакой информации. В экспериментальной физике число не приводят без погрешности и условий опыта; то же относится к производительности программ.

Электронная версия

Пособие поддерживается в актуальном состоянии в электронном виде, где собраны полные листинги, интерактивные графики и исправленные опечатки:

• Текст книги: https://phys-dev.github.io/soft-dev-book/
• Исходники и задания: https://github.com/phys-dev

Там же размещено приложение с экспресс-курсом по основам языка, NumPy и Matplotlib, в печатное издание не вошедшее: пересказывать документацию на бумаге нецелесообразно.

Замеченные ошибки и предложения направляются в issues репозитория; они будут учтены в следующем издании.

О себе

Меня зовут Федоров Вячеслав Васильевич. С 2018 года я работаю в Институте ядерной физики им. Г. И. Будкера СО РАН, с 2026 года — младшим научным сотрудником в секторе 5-13. Область моих научных интересов — моделирование динамики заряженных частиц в электромагнитных полях и разработка программ, обеспечивающих настройку ускорительных комплексов. Окончил НГУ по направлению «Физика».

В последние годы я участвую в пуско-наладочных работах на линейном ускорителе инжектора ЦКП «СКИФ»: измерение энергии и эмиттанса пучка, коррекция орбиты, автоматизация настройки оптики. Многие примеры пособия представляют собой упрощённые версии задач, решавшихся на этой установке.

Программы, разработанные в рамках этой работы, разобраны в пособии:

• REDPIC рассчитывает динамику пучка методом макрочастиц по релятивистской разностной схеме (№ 2023688768 от 25.12.2023);
• KENV осуществляет быстрый расчёт огибающей пучка по уравнению Капчинского—Владимирского (№ 2024611244 от 18.01.2024);
• SCAUT оркеструет эксперименты на ускорителях, объединяя управление, диагностику и моделирование в единой системе (№ 2025619977 от 21.04.2025); её слои разобраны в главе «От скрипта к приложению»;
• ACCUMULATOR является цифровым двойником установки, неотличимым от неё для остальных программ (№ 2026668488 от 07.07.2026);
• SAVA обеспечивает поддержку оператора в пультовой, связывая приборы, документацию и журнал смены на естественном языке (свидетельство пока не оформлено).

С 2021 по 2024 год я параллельно занимался разработкой коммерческого программного обеспечения: микросервисов для финансовой организации, модулей статического анализа кода, приложения, распознающего диагнозы в медицинских картах. Из этого опыта в пособие вошли главы про жизненный цикл программы, тестирование, непрерывную интеграцию и базы данных. В физической лаборатории этому обычно не учат, тогда как необходимость в этих навыках не меньше.

В 2017 и 2018 годах я разрабатывал на C++ программу инфракрасного датчика горизонта для сверхмалого космического аппарата НГУ «Норби», запущенного в 2020 году.

В НГУ я читаю лекции и веду семинары по применению Python в физических исследованиях и по основам искусственного интеллекта. Настоящее пособие выросло из этого курса.

Дополнительные сведения об авторе приведены на странице автора.

Применение ИИ для разработки ПО

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

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

Поэтому изложение строится на измерениях. Рассматривается, откуда эти инструменты появились и почему появились только сейчас; что говорят об их влиянии на скорость работы данные, полученные в аккуратно поставленных экспериментах; как модель устроена внутри, в объёме, достаточном для понимания природы её ошибок; какие формы инструментов существуют и чем они отличаются; как одна такая форма выглядит вблизи, на примере самого распространённого плагина к редактору. Завершают раздел ответы на вопросы, задаваемые студентами чаще всего, включая вопрос, считается ли это списыванием, и глава про Git, без которого работа с ассистентом, переписывающим по десятку файлов за раз, представляет опасность.

Инструмент усиливает того, кто понимает, что делает, и подводит того, кто не понимает. Код, который студент не может объяснить, нельзя сдавать независимо от того, кем он написан: ответственность за строку, сгенерированную моделью, остаётся на подписавшем работу.

Слайды к главе. Материал главы и её разделов изложен также в первой половине лекции «ИИ и Git» с демонстрациями в терминале и в редакторе кода; слайды лекции доступны на сайте книги и в PDF.

Контекст и скорость изменений

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

Маховик раскручивался давно

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

• 2012 г. AlexNet выигрывает соревнование ImageNet, показав, что глубокие свёрточные сети, обученные на графических ускорителях, решают задачи компьютерного зрения лучше методов, накопленных за предыдущее десятилетие. Отсюда начинается современная эпоха глубокого обучения.
• 2014 г. Ян Гудфеллоу предлагает генеративно-состязательные сети (GAN), устроенные как пара соперников; впервые нейросети начинают убедительно порождать данные, а не только раскладывать готовые по классам.
• 2017 г. Статья «Attention Is All You Need» вводит архитектуру трансформера. Трансформер лежит в основе практически всех больших языковых моделей, выпущенных с тех пор, а попытки обойтись без него редки.
• 2018–2020 гг. Обнаруживаются законы масштабирования, связывающие качество модели с числом параметров, объёмом данных и вычислительным бюджетом: качество предсказуемо улучшается при их согласованном росте. Появляются GPT-2 и GPT-3.
• 2022 г. Выходит ChatGPT. Прорыв произошёл не в архитектуре, а в дообучении под диалог и в удобном интерфейсе, добавленном к модели, существовавшей и раньше. Этого оказалось достаточно, чтобы технология вышла за пределы сообщества, следившего за ней десять лет.

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

Скорость распространения

Миллион пользователей ChatGPT набрал за пять дней. Instagram потребовалось около двух с половиной месяцев, Airbnb и Netflix — годы. Этой скоростью объясняется и объём инвестиций: сотни миллиардов долларов, вложенных в дата-центры и обучение моделей.

Инструмент, освоенный большинством коллег, становится частью профессионального минимума, подобно тому как это произошло с системой контроля версий двадцать лет назад. Отказ от него требует обоснования.

Оговорка о сингулярности

В обсуждениях ИИ часто встречается слово «сингулярность», обозначающее гипотетическую точку, после которой технологический рост становится неуправляемо быстрым. Руководители индустрии поддерживают эту риторику; Сэм Альтман в июне 2025 года написал:

Мы прошли горизонт событий; взлёт начался.

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

Полезные ссылки

• Vaswani A. et al. Attention Is All You Need. Статья, с которой начались большие языковые модели.
• Блог Сэма Альтмана. Взгляд индустрии изнутри, с поправкой на интерес автора.
• Epoch AI. Независимая аналитика по темпам развития ИИ и вычислительным затратам, собранная по открытым источникам.

ИИ и разработчик

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

Насколько это распространено

По опросу Stack Overflow 2024 года, охватившему десятки тысяч человек, около двух третей разработчиков уже применяли ИИ-инструменты в работе, и ещё примерно каждый седьмой собирался начать. В следующих выпусках опроса доля продолжает расти.

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

Расхождение ощущений и измерений

В 2025 году организация METR провела эксперимент, поставленный со строгим контролем. Опытным разработчикам, годами ведущим проекты с открытым кодом, давали задачи в их собственных, хорошо знакомых им репозиториях, причём часть задач, выбранная случайным образом, решалась с ИИ-ассистентом, а часть без него. С ассистентом задачи выполнялись примерно на 19% медленнее. Сама цифра значит немного; важен знак, противоположный тому, чего ожидали и авторы, и участники.

Те же участники, опрошенные после эксперимента, были уверены, что ИИ ускорил их работу примерно на 20%. Ощущение разошлось с замером почти на 40 процентных пунктов.

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

Отсюда следуют два практических вывода:

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

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

Полезные ссылки

• Stack Overflow Developer Survey: раздел про ИИ. Ежегодные данные, собранные по десяткам тысяч анкет: чем пользуются разработчики.
• METR. Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. Исследование, разобранное выше; рекомендуется к прочтению целиком, включая обсуждение ограничений.

Технические основы

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

Принцип работы языковой модели

Большая языковая модель (LLM) решает одну задачу: предсказывает по имеющемуся тексту, какой фрагмент будет следующим. Всё остальное (диалог, генерация кода, объяснения) надстроено над этим механизмом.

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

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

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

Причины уверенных ошибок модели

Здесь заключена главная причина, по которой ИИ-ассистент не заменяет понимания.

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

• аргумент функции, придуманный по аналогии: в документации его нет, однако «логично было бы иметь»;
• правдоподобная, но выдуманная ссылка на статью или страницу документации;
• формула с перепутанным коэффициентом, выглядящая уверенно;
• библиотека с осмысленным названием, которой не существует.

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

Из чего складываются характеристики модели

• Размер. Число обучаемых параметров, от единиц миллиардов до триллионов. Чем модель больше, тем более тонкие зависимости она способна уловить, но тем дороже и медленнее её работа. Для простых задач небольшая модель отвечает быстрее и дешевле при том же результате.
• Контекстное окно. Число токенов, которое модель видит за раз, включая вопрос пользователя, приложенные файлы и собственный ответ. Это главный практический предел: в окно должен поместиться весь код, о котором задаётся вопрос, вместе с историей разговора. Чем ближе к пределу, тем хуже модель удерживает детали из середины контекста.
• Способность к рассуждению. Часть моделей обучена перед ответом порождать промежуточные шаги рассуждения. Такие модели сильнее в задачах, требующих многошагового вывода (математика, отладка), но отвечают дольше и стоят дороже.

По причине, оговорённой в начале раздела, названия моделей и цены здесь не приводятся. Сравнение по качеству, скорости и стоимости ведут независимые площадки, Artificial Analysis и OpenRouter.

Формулировка запросов к модели

Способы формулировать запрос называют промтингом:

• Zero-shot. Задать вопрос. Работает для типовых задач.
• Few-shot. Приложить один-два примера в нужном формате. Повышает шансы получить ответ по образцу.
• Chain-of-thought. Попросить рассуждать по шагам. Помогает там, где нужен многошаговый вывод; в «рассуждающих» моделях встроено по умолчанию.

Качество ответа определяется не изяществом формулировки, а тем, что модель видит. Если ей предоставлены нужный файл, сообщение об ошибке целиком, фрагмент документации, то и посредственный запрос даёт результат. Без них модель начинает додумывать недостающее. Этот подход, названный контекст-инжинирингом, важнее промтинга.

Агенты

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

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

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

Полезные ссылки

• Attention Is All You Need. Оригинальная статья о трансформере.
• Anthropic. Building Effective Agents. Разбор того, как устроены агентные системы и когда они оправданы.
• Artificial Analysis. Независимое сравнение моделей по качеству, скорости и цене.

Задание. Простейшую языковую модель предлагается реализовать самостоятельно: «Генерация текста на основе данных». Цепь Маркова, реализованная за вечер, показывает и откуда берётся связность, и откуда берутся выдумки.

Инструментарий

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

Три формы инструментов

Первая, наиболее простая для входа, — плагин к редактору. Он устанавливается в привычную разработчику среду (VS Code, JetBrains, Neovim) и работает внутри неё, ничего не нарушая. Наиболее известный — GitHub Copilot; бесплатный тариф у него предусмотрен для всех, а для студентов бесплатен полный, о чём подробнее говорится в следующей главе.

Вторая форма — редактор, спроектированный вокруг ассистента: отдельная среда разработки, в которой модель видит проект целиком, а не только открытый файл. Большинство таких редакторов выросло из VS Code, поэтому переход почти не требует привыкания, а настройки и расширения переносятся. Примерами являются Cursor и Windsurf.

Третья форма — терминальный агент, работающий в командной строке в каталоге проекта. Он читает файлы, правит их, запускает тесты и разбирает вывод. Эта форма лучше остальных подходит для больших проектов и удалённых машин без графической оболочки — обычная ситуация для физика, работающего на кластере по SSH. Так работают Claude Code, Aider и Gemini CLI.

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

Возможности инструментов

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

• Автодополнение. Модель предлагает продолжение по ходу набора. Подсказка серым текстом выглядит правдоподобно, и её легко принять без чтения.
• Правка выделенного. Разработчик выделяет фрагмент кода и указывает, что с ним сделать, например «добавь обработку ошибок», «перепиши через генератор», «векторизуй этот цикл».
• Чат по проекту. Диалог, позволяющий сослаться на файлы. Подходит для вопроса «почему это падает» с приложенным трейсбеком.
• Агентный режим. Задача ставится целиком, а агент сам читает нужные файлы, вносит правки, запускает тесты и исправляется по упавшим.

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

Правила проекта

Все зрелые инструменты читают из репозитория файл с правилами, описывающий, как принято писать код в проекте. Агент подмешивает его в каждый запрос, и повторять одно и то же не приходится.

Сюда записываются договорённости, принятые в группе:

- Код на Python 3.12, стиль — PEP 8, длина строки 79 символов.
- Единицы СИ везде, кроме энергии частиц: она в МэВ.
- Массивы обрабатываем векторизованно, циклов по элементам не пишем.
- Новый код сопровождается тестом в tests/.
- Данные экспериментов в репозиторий не коммитим.

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

MCP: подключение собственных инструментов к агенту

Model Context Protocol (MCP) — открытый протокол, предложенный Anthropic в конце 2024 года и принятый остальными участниками отрасли.

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

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

Меры предосторожности

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

1. Только под контролем версий. Всё, сделанное агентом, должно быть видно в git diff и откатываться одной командой; о Git речь пойдёт в конце этой части.
2. Чтение перед принятием. Отказаться от непонятной правки дешевле, чем впоследствии искать в ней ошибку.
3. Мелкими шагами. Задача «перепиши мне весь модуль» даёт результат, который невозможно вычитать в разумное время. Задача «вынеси этот кусок в функцию и добавь тест» проверяется легко.
4. Запрет на разрушительные команды. Удаление файлов, git push и отправка чего-либо наружу остаются решением, принимаемым человеком, а не агентом.
5. Ответственность на разработчике. Автором кода считается человек, поставивший под ним коммит. Ссылка на то, что «так предложил ассистент», не работает ни в ревью, ни в статье.

Полезные ссылки

• Документация Model Context Protocol. Спецификация и серверы, написанные сообществом.
• Anthropic. Building Effective Agents. Когда агент оправдан, а когда достаточно запроса в чате.
• Aider. Терминальный агент с открытым исходным кодом, удобный для знакомства с этой формой работы.

GitHub Copilot

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

Назначение GitHub Copilot

GitHub Copilot — плагин к редактору, дописывающий код за разработчиком. Он был создан компанией GitHub совместно с OpenAI; первая версия, выпущенная в 2021 году, опередила ChatGPT на полтора года.

Проще говоря. Copilot работает как автодополнение, видящее контекст всего файла, а не только набираемую строку.

Под тем же названием сегодня существуют чат по проекту, агентный режим, самостоятельно правящий файлы, отдельный агент для командной строки и автоматическое ревью пул-реквестов, то есть все три формы, рассмотренные в предыдущей главе. Начинать лучше с автодополнения: оно требует меньше всего доверия к модели, а к остальным формам можно перейти после того, как выработан навык чтения предложенного кода.

Польза для студентов

Попробовать его можно без подписок: бесплатный тариф предоставляется любому владельцу аккаунта GitHub и ограничен числом автодополнений и запросов в чат за месяц, а студенту, оформившему Student Developer Pack, предоставляется полный тариф без этих ограничений.

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

Всё сказанное работает только при условии, что предложенное читается. Принятое без чтения предложение представляет собой отложенную отладку.

Начало работы

Установка и настройка

1. Требования:

   • Аккаунт на GitHub
   • Тариф Copilot: бесплатный включается на любом аккаунте, полный активируется студенческим пакетом
   • Поддерживаемая среда: VS Code, JetBrains, Visual Studio, Neovim и другие

2. Установка (на примере VS Code):

   • установить расширение «GitHub Copilot» из встроенного магазина;
   • авторизоваться через GitHub по запросу расширения;
   • при желании активировать студенческий пакет в настройках аккаунта, чтобы снять ограничения бесплатного тарифа.

Активация студенческой подписки

1. Перейти на education.github.com
2. Подать заявку на Student Developer Pack
3. Активировать Copilot в настройках аккаунта

Эффективное использование Copilot

Базовые приёмы работы

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

1. Комментирование намерений:

   # Напиши функцию для расчёта среднего значения списка
   # Copilot предложит:
   def calculate_average(numbers):
       return sum(numbers) / len(numbers) if numbers else 0
   

2. Создание шаблонов функций:

   function calculateCircleArea(radius) {
     // Copilot предложит:
     return Math.PI * radius * radius;
   }
   

3. Работа с библиотеками:

   import numpy as np
   # Создать массив из 10 случайных чисел от 1 до 100
   # Copilot предложит:
   arr = np.random.randint(1, 101, 10)
   

Продвинутые сценарии

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

Генерация тестов:

# Функция сложения двух чисел
def add(a, b):
    return a + b

# Напиши тесты для этой функции
# Copilot предложит:
def test_add():
    assert add(2, 3) == 5
    assert add(-1, 1) == 0
    assert add(0, 0) == 0

Рефакторинг кода:

// Старый код
function processData(data) {
    let result = [];
    for (let i = 0; i < data.length; i++) {
        if (data[i].active) {
            result.push(data[i].value * 2);
        }
    }
    return result;
}

// Добавь комментарий: "Рефакторинг с использованием map и filter"
// Copilot предложит:
function processData(data) {
    return data
        .filter(item => item.active)
        .map(item => item.value * 2);
}

Примеры для учебных задач

Ниже приведены два примера на заданиях второго курса. Комментарий разработчика задаёт задачу, Copilot дописывает остальное; предложенное полезно сравнить с тем, что было бы написано самостоятельно.

Для курса по алгоритмам

# Реализуй быструю сортировку на Python
# Copilot предложит:
def quicksort(arr):
    if len(arr) <= 1:
        return arr
    pivot = arr[len(arr) // 2]
    left = [x for x in arr if x < pivot]
    middle = [x for x in arr if x == pivot]
    right = [x for x in arr if x > pivot]
    return quicksort(left) + middle + quicksort(right)

Для курса по физике

# Рассчитать траекторию движения тела под углом к горизонту
# Copilot предложит:
def calculate_trajectory(initial_velocity, angle_degrees, times):
    import math
    g = 9.81
    angle_rad = math.radians(angle_degrees)
    vx = initial_velocity * math.cos(angle_rad)
    vy = initial_velocity * math.sin(angle_rad)
    
    trajectory = []
    for t in times:
        x = vx * t
        y = vy * t - 0.5 * g * t**2
        if y < 0:
            break
        trajectory.append((x, y))
    return trajectory

Важные ограничения и предостережения

Типичные ошибки Copilot

Ошибки делятся на три вида, и все три обнаруживаются чтением.

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

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

Академическая честность

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

Лучшие практики для студентов

Пять рабочих привычек:

1. Точная формулировка задачи. Чем конкретнее комментарий, тем ближе предложение к задуманному
2. Чтение предложения целиком. Прежде всего рассматриваются граничные случаи: пустой список, деление на ноль, отсутствующий файл
3. Проверка тестом, а не взглядом. Короткий тест на паре значений отвечает надёжнее самого внимательного чтения
4. Передача шаблонной работы. Разбор аргументов командной строки, чтение форматов данных, однотипные графики
5. Рассмотрение не только первого варианта. Copilot показывает одно решение из многих, и не всегда лучшее

Заключение

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

Таким образом, Copilot следует использовать, чтобы углубить понимание, а не чтобы обойтись без него.

Вопросы и ответы

Ниже разобраны вопросы, задаваемые студентами чаще всего.

Какую модель выбрать для работы с кодом?

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

Выбор определяют три параметра: качество на рассматриваемом типе задач, размер контекстного окна (поместится ли в него проект) и стоимость. Для рутины обычно достаточно модели поменьше и подешевле, тяжёлая нужна только для сложной отладки.

Сложно ли внедрить это в старый большой проект?

Сложность растёт с размером кодовой базы. Чем больше проект, тем меньшая его часть помещается в контекстное окно и тем важнее уметь показать модели нужные файлы. Помогают инструменты, умеющие искать по репозиторию самостоятельно; терминальные агенты, запущенные из корня проекта, справляются с этим обычно лучше, чем автодополнение в редакторе.

Начинать лучше не с кода, написанного предшественниками, а с того, чего в проекте не хватает, поручив ассистенту тесты к уже работающим функциям, docstring'и и README. Так становится видно, насколько модель понимает проект.

Может ли ИИ придумать что-то принципиально новое?

Модель сильна настолько, насколько задача похожа на то, что встречалось в обучающих данных. Она может неожиданно скомбинировать известные приёмы и подсказать подход, неизвестный исследователю, но нового метода не изобретёт. Её сильные стороны — скорость, объём и знание решений, накопленных сообществом, но не оригинальность.

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

Как начать применять это в научной работе?

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

1. Шаблонный код. Разбор форматов данных, переименование файлов, конвертеры. Ошибка проявится сразу.
2. Объяснение чужого кода. Ассистенту поручается разобрать скрипт, доставшийся от предшественника. Проверяется чтением исходника.
3. Документация и тесты к собственному уже работающему коду. Тесты заодно проверят и сам код.
4. Отладка. Прикладывается трейсбек целиком, а не пересказ, записанный по памяти.
5. Автоматизация рутины вокруг расчётов: запуск серий, сбор результатов, сводные графики.

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

Можно ли пользоваться ИИ при выполнении заданий курса?

Можно и нужно, с одним условием. Студент обязан понимать каждую сдаваемую строку и уметь её объяснить. На защите задания будет задан вопрос, почему здесь сделано так. Отсутствие объяснения означает, что задание не засчитано, кем бы ни была написана сданная строка.

Git

Git — распределённая система контроля версий (version control system, VCS): она хранит историю изменений файлов, позволяет вернуться к любой прошлой версии и объединяет работу нескольких человек над одним проектом. Для научной работы Git является таким же обязательным инструментом, как Python или LaTeX.

Слайды к главе. Материал главы изложен также во второй половине лекции «ИИ и Git» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Назначение контроля версий

Рассмотрим типичную курсовую работу с расчётами:

processing.py
processing_new.py
processing_final.py
processing_final_v2.py
thesis_final_v2_FINAL(2).py
thesis_final_v2_FINAL(2)_fixed_mass.py

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

Контроль версий решает три проблемы:

• История вместо множества файлов. В проекте хранится один processing.py, а все его прошлые версии остаются в Git. К любой из них можно вернуться, любые две можно сравнить построчно.
• Воспроизводимость расчётов. Каждое состояние проекта имеет уникальный идентификатор, хеш коммита. Если записать его рядом с результатом, через год код, построивший график, восстанавливается дословно. Запись «Рисунок 3 построен на коммите a3f2c17» и является воспроизводимостью.
• Совместная работа. Когда над обработкой данных работают три человека, Git объединяет их изменения и показывает, кто, что и зачем изменил. Пересылать архивы code_v7_new.zip по почте не требуется.

Репозиторий на сервере служит и резервной копией: после вечерней отправки изменений на сервер выход из строя диска ноутбука перестаёт быть катастрофой.

Устройство Git

Устройство Git основано на трёх идеях, из которых выводится почти всё поведение команд.

Снимки, а не различия

Git хранит не «патчи к предыдущей версии», а снимки (snapshots). Каждый коммит представляет собой состояние всего проекта в момент фиксации плюс метаданные: автор, дата, сообщение и ссылка на родительский коммит. Неизменившиеся файлы не копируются, Git ссылается на уже сохранённые объекты, и репозиторий не разрастается.

Каждый объект адресуется хешем SHA-1, строкой вида a3f2c17b... из git log; в командах достаточно первых 6–8 символов.

Три состояния

Файлы проекта находятся в трёх зонах:

рабочая директория  ──►  индекс (staging area)  ──►  репозиторий (.git)
  правишь файлы          git add: отбираешь           git commit:
                         изменения для коммита        фиксируешь снимок

• Рабочая директория (working directory) содержит обычные файлы, которые редактирует разработчик.
• Индекс (staging area) — промежуточная область перед коммитом. Командой git add в неё помещаются изменения, которые войдут в следующий снимок.
• Репозиторий находится в скрытой папке .git, хранящей все коммиты. Коммит, недостижимый ни через ветку, ни через тег, сохраняется ещё около месяца записью в git reflog, а затем удаляется сборщиком мусора, поэтому спасательный приём из справочной таблицы в конце главы действует ограниченное время.

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

Коммиты образуют граф

Каждый коммит ссылается на родителя, поэтому история образует направленный ациклический граф (DAG). Пока над проектом работает один человек, граф вырождается в цепочку; ветки заставляют его ветвиться, слияния — сходиться.

A ─── B ─── C ─────── F      main
       └── D ─── E ───┘      fft-filter

Ветка — подвижный указатель на коммит, файл размером 41 байт внутри .git; копия проекта не создаётся, поэтому ветки создаются мгновенно и без затрат. HEAD указывает на текущее положение в графе.

Базовый цикл работы

Разовая настройка

# имя и почта автора попадут в каждый коммит
git config --global user.name "Lev Landau"
git config --global user.email "l.landau@g.nsu.ru"

# называть главную ветку main, как принято на GitHub
git config --global init.defaultBranch main

Создать или склонировать репозиторий

# превратить текущую папку в репозиторий (появится скрытая папка .git)
git init

# или склонировать существующий проект с сервера
git clone https://github.com/nsu-phys/beam-dynamics.git

Путь правки: рабочий каталог, индекс, коммит

В цикле, описанном ниже, проходит почти вся повседневная работа.

git status                  # что изменилось? (спрашивай постоянно)

git add processing.py       # добавить файл в индекс
git add plots/              # можно папку целиком
git add -p                  # интерактивно, по кускам — очень полезно

git commit -m "Учтена поправка на температуру датчика"

git status                  # убедиться, что всё зафиксировано

git status показывает состояние всех трёх зон и подсказывает следующий шаг. На первых порах эту команду имеет смысл вызывать до и после каждой операции.

Просмотр истории и различий

git log                     # полная история с авторами и датами
git log --oneline           # по строчке на коммит
git log --oneline --graph --all   # весь граф с ветками, псевдографикой

git diff                    # что поменялось, но ещё не добавлено в индекс
git diff --staged           # что уже в индексе и войдёт в коммит
git diff a3f2c17 HEAD -- processing.py  # как файл изменился со старого коммита

git show a3f2c17            # что именно сделал этот коммит

.gitignore: исключение файлов из репозитория

Git отслеживает только явно добавленные файлы, однако git status перечисляет всё содержимое каталога, от кешей Python до гигабайтных файлов с данными. Файл .gitignore в корне проекта задаёт, что нужно игнорировать. Заготовка для научного проекта приведена ниже:

# байткод и кеши Python
__pycache__/
*.pyc
.ipynb_checkpoints/

# виртуальное окружение
.venv/

# данные измерений и результаты расчётов — им не место в git
data/
*.h5
*.root
*.npz

# тяжёлые артефакты: чекпойнты моделей, дампы
checkpoints/
*.ckpt

# мусор редакторов и ОС
.idea/
.vscode/
.DS_Store

# LaTeX-мусор
*.aux
*.synctex.gz

В репозитории хранится написанное вручную (код, тексты, конфигурации) и не хранится измеренное на установке или полученное расчётом. Сам .gitignore фиксируется в репозитории: правила исключений являются общими для всей группы.

Ветки

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

git branch                    # список веток, звёздочка — текущая
git switch -c fft-filter      # создать ветку и переключиться на неё
# ...правишь и коммитишь сколько угодно...
git switch main               # вернуться на main: файлы мгновенно
                              # станут такими, какими были там

git switch появился в Git 2.23; в старых руководствах те же действия выполняются командами git checkout -b fft-filter и git checkout main.

Слияние

Когда эксперимент в ветке завершён успешно, ветка вливается обратно:

git switch main
git merge fft-filter          # влить коммиты fft-filter в main
git branch -d fft-filter      # удалить ненужный больше указатель

Если main с момента ветвления не изменялся, Git передвинет указатель вперёд (fast-forward). Если изменялся, будет создан коммит слияния с двумя родителями, и граф из приведённого выше рисунка сходится в одну линию.

Конфликты

Если в двух ветках изменены одни и те же строки, Git не будет выбирать версию самостоятельно и вставит в файл маркеры, размечающие оба варианта:

<<<<<<< HEAD
dt = 1e-12  # шаг интегрирования для жёсткой задачи
=======
dt = 5e-12  # компромисс между точностью и скоростью
>>>>>>> fft-filter

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

git add integrator.py         # пометить конфликт разрешённым
git commit                    # завершить merge

Если принято решение отказаться от слияния, вместо этих двух команд требуется одна:

git merge --abort             # откатить слияние целиком

После git commit сливать уже нечего, и git merge --abort сообщит, что отменять нечего.

Чем мельче коммиты и чем чаще выполняется слияние веток, тем реже возникают конфликты и тем проще они разрешаются.

Удалённые репозитории

Пока коммиты находятся только на ноутбуке разработчика, нет ни резервной копии, ни совместной работы. Удалённый репозиторий (remote) хранит копию проекта на GitHub, GitLab или на институтской машине группы.

git remote -v                  # список удалённых репозиториев
# после git clone там уже есть origin — адрес, откуда клонировал

# привязать локальный репозиторий к созданному на GitHub
git remote add origin git@github.com:username/beam-dynamics.git

git push -u origin main        # отправить ветку main на сервер;
                               # -u запоминает связку, дальше просто git push

git fetch                      # скачать чужие коммиты, НЕ трогая рабочие файлы
git pull                       # fetch + merge: скачать и влить в текущую ветку
git push                       # отправить свои коммиты

git fetch безопасен всегда: он лишь обновляет локальные сведения о сервере, после чего можно просмотреть git log origin/main и изучить коммиты коллег. git pull объединяет fetch с немедленным слиянием. Типовой ритм работы: в начале сеанса выполняется git pull, по окончании — git push. Чем чаще выполняется синхронизация, тем меньше конфликтов.

Fork + pull request

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

1. Fork. Кнопкой на GitHub создаётся личная копия репозитория в аккаунте разработчика.
2. Форк клонируется, создаётся ветка, фиксируется исправление.
3. Ветка отправляется в форк.
4. Открывается pull request (PR) — предложение включить коммиты в основной репозиторий, сопровождаемое описанием и дифом.
5. Владельцы читают код, пишут замечания (code review), автор дополняет ветку новыми коммитами, и PR обновляется автоматически.
6. Одобренный PR вливается в основной репозиторий.

По этой схеме работает весь open source и заметная часть открытой науки; исправление одной строки в документации scipy проходит тот же путь. Внутри своей группы обычно отправляют коммиты в общий репозиторий, однако правки всё равно оформляются ветками и PR ради ревью.

Хорошие практики

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

Не менее важно сообщение коммита. Слово fix не сообщает, что исправлено, где и почему; через полгода git log из fix, fix2 и wip превращается в длительные археологические раскопки. Диф и так покажет, что изменилось. Следует писать короткий заголовок с сутью изменения, не «поменял коэффициент», а «Увеличен шаг сетки: старый не помещался в память на кластере». По общепринятому соглашению заголовок укладывается в 50 символов и не превышает 72. Сообщение должно объяснять, зачем сделано изменение.

Git создан для текста и плохо работает с большими бинарными файлами. Каждый попавший в историю гигабайт останется в ней навсегда, и клонирование станет неприемлемо долгим. Сырые данные с установки, HDF5/ROOT-файлы, видео, обученные модели в репозиторий не помещают. Для версионирования больших файлов рядом с кодом существуют Git LFS (в git хранятся лишь ссылки, а содержимое находится на отдельном сервере) и DVC (Data Version Control, версионирующий данные и пайплайны обработки, а сами файлы размещающий в любом хранилище, будь то облако или сетевой диск группы). Пароли, токены и ключи фиксировать в репозитории недопустимо: удалить секрет из истории почти невозможно, а клоны коллег успевают разойтись.

Исправление ошибок

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

git reset --hard — одна из немногих команд, без предупреждения и необратимо уничтожающих незакоммиченную работу. Перед её выполнением необходимо вызвать git status и убедиться, что терять нечего. Историю переписывает и git rebase, переносящий коммиты ветки поверх другой так, как если бы они были сделаны там изначально: граф получается линейным и читаемым, однако перенесённые коммиты получают новые хеши, то есть прежних коммитов больше нет. Не следует переписывать историю (reset, --amend, rebase) в ветках, уже отправленных на сервер и полученных коллегами: им придётся разбираться с разошедшимся графом.

Полезные ссылки

• Введение в основы Git
• Создание алиасов команд
• Как просматривать историю изменений
• Один из подходов к созданию веток
• git rebase для начинающих
• Learn Git Branching, интерактивный тренажёр, в котором ветки, merge и rebase показаны на живом графе коммитов
• Oh Shit, Git!?!, короткие рецепты спасения из типичных ситуаций вида «всё сломано»
• Git Flight Rules, «лётные правила», большой сборник ответов, сгруппированных вокруг вопроса «что делать, если…»

Основы Linux

Под управлением Linux работают вычислительные кластеры, серверы установок и машины сбора данных, то есть практически всё оборудование, на котором выполняются физические расчёты. Независимо от того, ведётся ли разработка на ноутбуке с Windows или macOS, расчёт в итоге выполняется на такой машине. Рано или поздно наступает момент, когда он не запускается, заканчивается место на диске или процесс перестаёт отвечать, и разбираться с этим приходится самому исследователю.

В настоящей части рассматриваются инструменты, необходимые для повседневной работы в терминале, путь от включения питания до приглашения командной строки, организация хранения данных, сборка системы с нуля вручную, внутреннее устройство ядра (процессы, планировщик и память) и, наконец, контейнеры, построенные из этих механизмов ядра.

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

Слайды к главе. Материал части изложен также в трёх лекциях с демонстрациями в терминале: «Инструменты Linux», «Как организован Linux» (загрузка системы и файловые системы) и «Внутренности Linux»; слайды каждой из них встроены в соответствующие главы, а слайды лекции «Как организован Linux» доступны также на сайте книги и в PDF.

Инструменты Linux

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

Глава выстроена по нарастающей: сначала рассматривается обустройство рабочего места, затем основы командной строки, далее утилиты, необходимые каждый день, и, наконец, диагностика в ситуации, когда система работает не так, как ожидалось. Запоминать всё подряд не требуется: достаточно знать, что подходящий инструмент существует, а подробности всегда приведены в man.

Слайды к главе. Материал главы изложен также в лекции «Инструменты Linux» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Подготовка и окружение

Слепая печать

Первым навыком является умение печатать, не глядя на клавиатуру. Две вложенные недели окупаются годами: растёт скорость, растёт точность, а внимание постоянно остаётся на экране. В первые месяцы после переучивания скорость, набранная годами, снижается, и это является нормальным.

Инструменты для тренировки:

• GNU Typist (gtypist), консольный тренажёр. Устанавливается через apt-get install gtypist или brew install gtypist.
• monkeytype, современный онлайн-тренажёр.
• www.keybr.com, ещё один популярный онлайн-тренажёр.

Эмулятор терминала

Терминал, поставляемый в комплекте с системой, обычно способен только отображать текст. Полчаса, потраченные на установку полноценного эмулятора, окупаются быстро. Требуемые возможности:

• вкладки;
• разделение окна на панели;
• копирование в буфер обмена простым выделением текста;
• ссылки, открывающиеся по щелчку;
• плагины;
• темы, прозрачность и прочие мелочи, повышающие удобство работы.

Рекомендуемые терминалы:

• macOS: iTerm2
• Linux: Terminator, Kitty, Konsole
• Windows 10/11: Windows Terminal
• Windows (условно-бесплатный): MobaXterm (также включает SSH-клиент, X-сервер и сетевые инструменты).

Моноширинные шрифты

В моноширинном шрифте все символы имеют одинаковую ширину, поэтому колонки, выведенные командой, не смещаются, а отступы в коде различимы визуально. Хороший терминальный шрифт, кроме того, различает плохо отличимые символы, будь то ноль и заглавная O или единица и строчная l.

• Source Code Pro (Adobe)
• Inconsolata (Google)
• Anonymous Pro

Все три распространяются свободно и в большинстве дистрибутивов доступны в подключённых репозиториях.

Командные оболочки (Shell)

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

• bash (Bourne-Again SHell): универсальный стандарт. Присутствует на любой машине, доступной по ssh, поэтому переносимые скрипты пишутся под него.
• zsh (Z Shell): те же возможности плюс интеллектуальное автодополнение и богатая экосистема плагинов; настройку упрощает фреймворк Oh My Zsh. Разумный выбор для собственной рабочей машины.
• fish (Friendly Interactive SHell): подсказки по истории, подсветка и автодополнение работают сразу, без настройки. Платой является несовместимость с синтаксисом POSIX-оболочек: скрипт, написанный для bash, в fish не запустится.

Основы командной строки

Структура команд

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

• Оболочка ищет исполняемый файл по каталогам из переменной окружения $PATH и запускает его системным вызовом exec.
• which <команда> или type <команда> показывают полный путь к исполняемому файлу команды. Флаг -a показывает все возможные пути в $PATH.
• Флаги команд не стандартизированы, но существуют соглашения:
  • -v / --version показывают версию.
  • -h / --help показывают справку.
  • -y / -f пропускают подтверждение (yes/force).

Справка man

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

• Пейджер: По умолчанию для просмотра используется less. Его можно изменить переменной окружения $MANPAGER (например, MANPAGER=cat).
• Основные клавиши в less:
  • h вызывает помощь.
  • PgUp, PgDown, ↓, ↑ служат для навигации.
  • /KEYWORD запускает поиск.
  • n переходит к следующему совпадению, N к предыдущему.
  • g переносит в начало документа.
  • G переносит в конец документа.
• man <раздел> <команда>, например man 1 bash (справка по bash из раздела «пользовательские команды»).
• man -P 'less +/KEYWORD' bash открывает man с поиском по ключевому слову.

Управление процессами

Запущенной программой можно управлять из того же терминала. Все сочетания, перечисленные ниже, посылают процессу сигналы, устройство которых рассматривается в главе про внутреннее устройство Linux, а команды fg, bg и jobs определяют, на переднем плане процесс выполняется или в фоне.

• Ctrl + C посылает сигнал SIGINT (завершение процесса).
• Ctrl + \ посылает сигнал SIGQUIT (завершение с дампом памяти).
• Ctrl + Z посылает сигнал SIGTSTP (приостановка процесса).
• fg возвращает приостановленный процесс на передний план.
• bg запускает приостановленный процесс в фоновом режиме.
• jobs выводит список задач текущей оболочки с их номерами.
• stty -a показывает настройки терминала и позволяет их изменить.

Управление вводом/выводом (I/O Redirection)

У каждой запущенной программы имеются три открытых потока, а перенаправление подменяет то, куда они ведут. На нём основаны конвейеры: вывод одной программы становится входом другой, и ни одна из них об этом не знает.

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

• Потоки данных:
  • stdin (0), стандартный вход.
  • stdout (1), стандартный выход.
  • stderr (2), стандартный вывод ошибок.
• Перенаправление:
  • команда > файл записывает stdout в файл, перезаписывая его.
  • команда >> файл дописывает stdout в конец файла.
  • команда 2> файл записывает stderr в файл.
  • команда &> файл записывает stdout и stderr в файл.
  • команда 2>&1 перенаправляет stderr в stdout.
  • команда | другая_команда передаёт stdout первой команды на stdin второй.
• Специальные файлы:
  • /dev/null, «чёрная дыра».
  • /dev/zero, источник нулей.
  • /dev/urandom, источник псевдослучайных чисел.

Полезные помощники

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

• Автодополнение (completion): клавиша TAB.
  • Одно нажатие дополняет команду или файл.
  • Двойное нажатие показывает все возможные варианты.
• История команд (~/.bash_history, ~/.zsh_history):
  • Ctrl + R запускает реверсивный поиск по истории.
  • history | grep <ключевое_слово> ищет по истории.
  • sudo !! выполняет предыдущую команду с sudo.
  • !$ подставляет последний аргумент предыдущей команды.

Ветвления, циклы и подоболочки (Subshell)

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

• ; разделяет команды, выполняемые последовательно.
• Циклы и условия:

  while true; do ...; done
  for i in $(seq 1 10); do echo $i; done
  if [ "$(wc -l < file.txt)" -gt 3 ]; then ...; fi
  

• read, встроенная команда для чтения ввода в переменные.
• Подстановка команд (command substitution): $(команда) подставляет вывод команды в строку; сама команда выполняется в подоболочке, поэтому присвоенные в ней переменные наружу не передаются.
• Подоболочка (subshell): ( команда; команда ) — дочерняя копия оболочки со своими переменными и текущим каталогом, так что cd внутри скобок родительский каталог не меняет.
• [ является не элементом синтаксиса оболочки, а командой: в /usr/bin расположена одноимённая программа, хотя bash и zsh выполняют собственную встроенную. Отсюда и требование ставить пробелы вокруг скобок: без них это будет другое имя команды. Подробности: man [ или man test.

Полезные команды и утилиты

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

Find и многопоточность

Связка find и xargs применяет команду ко всем файлам, удовлетворяющим условию. Флаг -P у xargs превращает её в простейший параллельный запуск с заданным числом одновременных процессов. Выигрыш растёт с числом процессов, пока задача ограничена процессором; на обработке, ограниченной диском, он выходит на насыщение заметно раньше.

• find осуществляет мощный поиск файлов и директорий.
  • Пример: find /etc -type f -name "nginx*"
• xargs передаёт результаты из stdin в аргументы другой команды.
  • -P <N> запускает до N процессов параллельно.
  • -n1 передаёт по одному аргументу за раз.
  • -0 читает имена, разделённые нулевым байтом, — пара к find -print0; без неё имена с пробелами будут разбиты на части.
  • Пример: find /data -type f -print0 | xargs -0 -P10 -n1 md5sum
• GNU parallel служит более мощной альтернативой xargs для параллельного выполнения.

Управление сессиями: screen и tmux

Расчёт, запущенный по ssh, завершается вместе с обрывом связи, а связь с кластером обрывается регулярно. screen и tmux решают эту проблему: сессия, отвязанная от терминала, продолжает работать на сервере, а пользователь подключается к ней и отключается в любой момент, в том числе с другой машины. На кластере с планировщиком долгий расчёт отправляют в очередь командой sbatch, а считать на узле входа правила большинства центров запрещают, и tmux там служит для интерактивной работы; планировщик рассмотрен в главе «Кластеры и воспроизводимое окружение для расчётов».

• screen:

  • screen создаёт новую сессию.
  • Ctrl + A, D отключает от сессии (detach).
  • screen -ls выводит список сессий.
  • screen -r <session> подключает к сессии.

• tmux (рекомендуется):

  • tmux создаёт сессию.
  • Ctrl + B, D отключает от сессии.
  • tmux ls выводит список сессий.
  • tmux a -t <session> подключает к сессии.
  • Интеграция с iTerm2: tmux -CC.

• watch -d -n1 "команда" выполняет команду раз в секунду и подсвечивает меняющиеся значения.

Редактирование текста

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

• Vim:
  • Мощный редактор, присутствующий на любой машине, но с непривычным управлением, которое требует отдельного освоения.
  • vimtutor, встроенный интерактивный учебник на полчаса.
  • Основы: i включает режим вставки, ESC возвращает в нормальный режим, :wq сохраняет и выходит, :q! выходит без сохранения.
  • vimdiff file1 file2 сравнивает файлы.
• Emacs: другой мощный редактор со своей философией и своими сторонниками.
• Git: система контроля версий, без которой сегодня не обходится ни один проект; ей посвящена отдельная глава. Для сообщения коммита git открывает редактор, заданный настройкой core.editor или переменными окружения VISUAL и EDITOR. Если ничего не задано, в Ubuntu и Debian открывается системный редактор по умолчанию, обычно nano (подсказки клавиш показаны внизу экрана: Ctrl+O сохраняет файл, Ctrl+X выходит), а в macOS и большинстве других систем — vi. Привычный редактор задаётся явно: git config --global core.editor vim.

Потоковая обработка текста

Каждая из этих утилит выполняет над текстовым потоком одну операцию, а соединяются они конвейером. Разбор журнала, извлечение колонки чисел, подсчёт уникальных значений укладываются в одну строку, набранную по ходу работы. Как только разбор перестаёт быть разовым и становится частью повторяемого конвейера обработки данных, его лучше переписать на Python: цепочку из пяти awk и sed через месяц невозможно ни прочитать, ни отладить.

• grep фильтрует строки по регулярному выражению.
• awk, целый язык для обработки текста, основанный на колонках.
• sed, потоковый редактор, правящий текст на лету (замена, удаление строк и т.д.).
• cut извлекает конкретные колонки.
• head и tail выводят начало и конец файла, а tail -f показывает строки, дописываемые в настоящий момент.
• tr заменяет или удаляет символы.
• wc считает строки, слова и символы.
• sort сортирует строки.
• uniq отфильтровывает повторяющиеся строки.

Тренажёры: grepexercises, sedexercises, awkexercises (устанавливаются через pip).

Практика: The Command Line Murders, детективный квест, расследуемый исключительно командами в терминале: https://github.com/veltman/clmystery

Диагностика и поиск проблем

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

Общий принцип диагностики состоит в движении сверху вниз по подсистемам (процессор, память, диск, сеть) с принятием на каждом шаге решения, здесь ли узкое место или дальше. Каждое предположение необходимо подтверждать измерением на работающей системе.

Методология и ресурсы

Карта инструментов, охватывающая всю систему целиком, составлена Бренданом Греггом (Brendan Gregg). На его сайте https://www.brendangregg.com/linuxperf.html приведены схемы, где каждая подсистема ядра подписана инструментами, которыми она измеряется. Схем четыре:

• Linux Observability Tools для наблюдения за работающей системой;
• Linux Static Performance Tools для сбора статической конфигурации, заданной до всякой нагрузки;
• Linux Benchmarking Tools для нагрузочного тестирования;
• Linux Tuning Tools для подстройки параметров ядра.

Первую, самую насыщенную, рекомендуется распечатать и разместить рядом с рабочим местом. У того же автора имеется книга «Systems Performance: Enterprise and the Cloud», справочник по всему, что в Linux измеримо.

Мини-топ полезных утилит

• Мониторинг процессов и системы:
  • top и htop показывают процессы в интерактивном режиме.
  • atop ведёт расширенный мониторинг и позволяет записывать данные в файл.
  • pidof находит PID по имени процесса.
  • ps fauxw | less даёт подробный список запущенных процессов.
• Диски и файловая система:
  • df -h и df -ih показывают место на дисках и inodes.
  • du -sh /path/* показывает размер директорий.
  • iostat -x 1 выводит статистику ввода-вывода.
• Сеть:
  • ss -s и netstat -ntlp выводят статистику сокетов и открытые порты.
  • ping, traceroute и mtr диагностируют сетевую связность.
  • tcpdump работает «сниффером», перехватывающим сетевые пакеты.
  • ethtool eth0 показывает настройки и статистику сетевого интерфейса.
• Прочее:
  • lsof -i:ПОРТ показывает, какой процесс держит порт, а lsof -p $PID — какие файлы и сокеты открыл процесс.
  • strace -fp $PID и strace $cmd трассируют системные вызовы.
  • dmesg -T показывает сообщения ядра с проставленными временными метками.
  • perf top -F99 профилирует систему в реальном времени.
  • curl — универсальный инструмент для работы с HTTP и сетью.

Заключение

Осваивать всё сразу не требуется. Рекомендуемый порядок следующий: сначала слепая печать и полноценный терминал, затем привычка обращаться к man вместо поисковой системы, затем tmux, позволяющий не терять работу на удалённой машине при обрыве связи, и уже после этого grep, awk и sed. Каждый следующий инструмент осваивается на реальной задаче, а не заранее и впрок.

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

Задание. Долгий расчёт, переживающий закрытие сессии: «Работа с долгоиграющими процессами».

Задание. Обустройство рабочего места в терминале и выполнение набора упражнений: «Настройка окружения и работа с утилитами».

Процесс загрузки

Микропрограмма, записанная в чип материнской платы, инициализирует оборудование. Загрузчик отыскивает ядро и запускает его. Ядро разворачивает временную файловую систему, монтирует настоящую и передаёт управление первому процессу. Монтированием называется подключение файловой системы в общее дерево каталогов; подробно этот вопрос рассматривается в следующей главе. Каждое звено цепочки передаёт управление следующему и завершается.

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

Слайды к главе. Материал главы изложен также в первой части лекции «Как организован Linux» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

1. BIOS (Basic Input/Output System)

BIOS — микропрограмма, хранящаяся на чипе материнской платы (во FLASH-памяти). При включении питания процессор выполняет первую инструкцию по фиксированному адресу 0xFFFFFFF0 (reset vector), где и расположен код BIOS.

Первым делом BIOS проводит самотестирование, называемое POST (Power-On Self-Test): проверяет целостность собственной микропрограммы, инициализирует процессор, установленную память и чипсет, а затем запускает прошивки остальных устройств, видеокарты и сетевой карты. Пока видеокарта не инициализирована, выводить сообщение об ошибке некуда, поэтому о результатах POST сообщает встроенный в плату динамик. Один короткий сигнал означает успех, комбинации длинных и коротких указывают на конкретную неисправность; расшифровка, приведённая в документации к плате, у каждого производителя своя.

2. Загрузчик (Bootloader)

Задача загрузчика — найти, загрузить в оперативную память и передать управление ядру операционной системы.

Схемы загрузки

Схем две, и различаются они возможностями прошивки.

Старую схему составляют BIOS + MBR (Master Boot Record). BIOS способен только прочитать первые 512 байт диска и передать им управление. В них размещаются 446 байт первичного кода загрузчика, 64 байта таблицы разделов (не более четырёх первичных) и два байта сигнатуры 55 AA. Код из MBR отыскивает активный раздел, помеченный особым флагом, и загружает оттуда следующую ступень загрузчика, например GRUB2. Из размера полей в таблице разделов следует и главное ограничение схемы: диски больше 2 ТБ ей недоступны.

Современную схему составляют UEFI + GPT (GUID Partition Table). UEFI читает файловые системы, в первую очередь FAT32, и проверяет цифровую подпись, поставленную на загрузчик (Secure Boot). Размещать код в первых секторах диска не требуется, поскольку прошивка обращается к обычному FAT32-разделу, EFI System Partition, где загрузчики хранятся обычными файлами с расширением .efi наподобие grubx64.efi, а список загрузочных записей хранится в энергонезависимой памяти материнской платы (NVRAM). Таблица разделов GPT ограничений MBR не наследует.

Полезные команды:

• Просмотр UEFI-записей: efibootmgr -v
• Просмотр разделов: fdisk -l

GRUB2 (Grand Unified Bootloader 2)

Самый распространённый загрузчик в Linux. Он показывает меню, в котором выбирается ядро или другая установленная система, загружает модули для работы с нужным оборудованием и файловыми системами и затем запускает выбранное ядро. Настройки хранятся в /boot/grub/grub.cfg, однако править этот файл вручную бессмысленно. Он собирается заново командой grub-mkconfig из /etc/default/grub и скриптов в /etc/grub.d/, и обновление ядра уничтожит ручную правку.

3. Ядро (Kernel)

Ядро Linux представляет собой сжатый исполняемый файл, расположенный обычно в каталоге /boot под именем vmlinuz-<версия>. Запуск осуществляется в три шага.

1. GRUB загружает в оперативную память два файла: сжатый образ ядра и образ initramfs.
2. Ядро распаковывается и запускается с параметрами командной строки, переданными загрузчиком (просмотреть их можно в /proc/cmdline).
3. Ядро разворачивает в памяти временную корневую файловую систему, называемую initramfs.

Initramfs (Initial RAM File System)

Внутри содержатся драйверы, модули ядра, микрокод процессора и скрипты ранней загрузки, собранные в один архив, то есть всё, без чего до настоящего диска не добраться. Задача initramfs — смонтировать настоящий корень (/) и передать управление процессу init.

Промежуточная ступень необходима из-за замкнутого круга. Ядро должно смонтировать корень, но драйвер нужного контроллера или файловой системы может быть собран отдельным модулем, а модули, вынесенные из ядра, хранятся на этом корне. Замкнутый круг разрывает initramfs, содержащий всё необходимое, чтобы добраться до настоящего диска, даже если тот зашифрован или собран в RAID.

4. Init и systemd

Процесс с PID 1 (init или systemd) является прародителем всего, что работает в системе; ему же достаются осиротевшие процессы. Он запускает службы в правильном порядке, монтирует файловые системы по описанию, заданному в /etc/fstab, и следит за тем, что уже запущено.

systemd — самая распространённая сегодня реализация init. Всё, чем он управляет, описано однотипными объектами, называемыми юнитами (units). Юнитом может быть служба, точка монтирования, сокет или таймер, запускающий задачу по расписанию. Зависимости между ними показывает systemctl list-dependencies default.target, а повседневная работа сводится к двум утилитам: systemctl управляет юнитами, journalctl показывает их журналы.

Задание. Пройти загрузку вручную, от разметки диска до записи в efibootmgr: «Установка Arch Linux вручную с RAID1 и UEFI».

Файловые системы

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

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

Слайды к главе. Материал главы изложен также во второй части лекции «Как организован Linux» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

1. Немного о дисках

Классический жёсткий диск состоит из пластин, разделённых на дорожки и секторы (обычно по 512 байт или 4 КБ). У SSD пластин нет, но наружу он предоставляет всё тот же интерфейс из пронумерованных секторов одинакового размера. Файловая система этой разницы почти не замечает. Располагается она внутри раздела, описанного в таблице MBR или GPT.

2. Задачи файловой системы

ФС решает несколько задач:

• Индексация и поиск данных (через структуры наподобие inode).
• Управление свободным пространством, то есть учёт блоков, остающихся незанятыми.
• Контроль доступа (права, ACL).
• Оптимизация производительности (кеширование, дефрагментация*).
• Надёжность (журналирование).

*Дефрагментация менее критична для современных ФС (ext4, XFS, btrfs) и SSD.

3. Виды файловых систем

Все файловые системы Linux скрывает за единым интерфейсом, называемым VFS (Virtual File System). Благодаря ему open и read работают одинаково и на локальном ext4, и на сетевом NFS, и на псевдофайлах из /proc, а программе, вызывающей их, не требуется знать, с чем она имеет дело.

FAT (File Allocation Table)

FAT происходит из эпохи дискет; сегодня она применяется для флеш-накопителей, которые должны открываться на любом компьютере, и для EFI-раздела, с которого загружается установленная система.

• Плюсы: простая, читаемая всеми операционными системами.
• Минусы: журналирования нет, а размеры, заложенные в формат, ограничены: в FAT32 файл не больше 4 ГБ, а раздел штатными средствами Windows не отформатировать больше 32 ГБ.
• Происхождение чисел в названии: 12, 16 и 32 обозначают разрядность номера кластера в таблице размещения. Предельный размер тома получается умножением числа кластеров на размер кластера, но самих кластеров несколько меньше, чем даёт разрядность: несколько старших номеров занято служебными метками, зарезервированными под «конец файла» и «сбойный кластер». У FAT12 их 4084, а не 4096. У FAT32 под номер отведено 28 бит из 32, а старшие четыре не используются.

ext4 (Fourth Extended Filesystem)

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

• Стандарт для Ubuntu, Debian и многих других дистрибутивов.
• Журналируемая, то есть повышающая надёжность записью метаданных операций в специальный журнал перед их выполнением.
• Использует экстенты (extents), описывающие непрерывный диапазон блоков, для более эффективного хранения больших файлов (вместо прямых и косвенных блоков).
• Иноды (inodes) хранят метаданные о файле (права, владелец, указатели, ведущие к данным). Их количество ограничено числом, заданным при создании ФС.

XFS

XFS создавалась для больших файлов и параллельного доступа с десятков узлов. Её применяют там, где на диск записываются многогигабайтные наборы наподобие архивов эксперимента и дампов, полученных при моделировании.

• Высокопроизводительная ФС, подходящая для работы с большими файлами.
• Использует B+-tree для индексации.
• Отложенная аллокация, улучшающая производительность.
• Иноды, создаваемые динамически, по мере необходимости.
• Стандарт для Red Hat Enterprise Linux.

btrfs (B-Tree File System)

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

• Современная ФС с продвинутыми функциями.
• Copy-on-Write (CoW): при изменении файла данные записываются в новое место, а не перезаписываются старые. Это и обеспечивает дешёвые снапшоты (snapshots).
• Встроенная поддержка RAID и LVM-подобных функций.
• Субаллокация, обеспечивающая эффективную работу с маленькими файлами.
• Поддержка TRIM, сообщающего SSD об освободившихся блоках.
• Стандарт для openSUSE.

4. Конфигурирование файловой системы

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

• Кеширование: прочитанные с диска страницы ядро хранит в page cache, откуда повторное чтение того же файла выполняется уже из памяти. Изменённые, но ещё не записанные на диск страницы называют «грязными» (dirty). Отдельного кеша для них нет: это состояние страниц внутри того же page cache. Сбрасывает их фоновый механизм, работающий по таймеру, а принудительно — вызов sync.

• Планировщики ввода-вывода: определяют, в каком порядке запросы передаются на диск. Текущий и доступные приведены в /sys/block/<device>/queue/scheduler. Начиная с ядра 5.0 остались только многоочередные планировщики:

  • none работает без переупорядочивания, как обычный FIFO. Обычно является лучшим выбором для NVMe-накопителей, которым перестановка запросов ничего не даёт.
  • mq-deadline следит за сроками выполнения запросов, не позволяя им зависать. Разумное значение по умолчанию для SATA-дисков и SSD.
  • bfq «честно» распределяет полосу между процессами; полезен на настольной системе, где важна отзывчивость.
  • kyber является простым планировщиком для быстрых устройств, ограничивающим задержки.

  Старые одноочередные планировщики cfq, deadline и noop из ядра удалены, но их названия ещё встречаются в статьях.

Утилиты для работы с ФС:

• mkfs, mke2fs создают ФС.
• tune2fs изменяет параметры ФС ext*.
• debugfs отлаживает ФС ext*.
• fsck проверяет ФС и восстанавливает структуры, повреждённые сбоем.

5. Монтирование

В Linux нет букв дисков: любая файловая система подключается в общее дерево каталогов, растущее из корня, в выбранную точку монтирования наподобие /mnt, /home или /data. Пока раздел не смонтирован, данные на нём недоступны.

• Команды: mount, umount.
• /etc/fstab хранит описания файловых систем, монтируемых при загрузке автоматически.

  # Пример строки в /etc/fstab
  UUID=ed465c6e-949a-41c6-8e8b-c8da348a3577 / ext4 defaults 0 1
  

• Параметры монтирования: rw/ro (чтение и запись или только чтение), noatime (не обновлять время последнего доступа, что на архиве, состоящем из миллионов файлов, заметно экономит записи), acl (поддержка списков контроля доступа) и другие.
• systemd.mount является альтернативой fstab, построенной на юнитах systemd.

6. RAID (Redundant Array of Independent Disks)

RAID объединяет несколько физических дисков в один логический массив, видимый системе как обычный диск. Цель — либо пережить отказ диска без потери данных, либо сложить скорости нескольких дисков, работающих одновременно, а в некоторых уровнях и то и другое.

В колонке «Ёмкость» \(N\) обозначает число дисков в массиве (все одинакового размера). У RAID 1, сколько бы дисков ни было собрано в зеркало, полезная ёмкость равна ёмкости одного диска: остальные хранят копии записанного. Поэтому зеркало почти всегда собирают из двух дисков.

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

Создание программного RAID в Linux: Аппаратный контроллер не требуется: массив собирает ядро, а управляет им утилита mdadm.

# Пример создания RAID 1
mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdb /dev/sdc
mkfs.ext4 /dev/md0
mount /dev/md0 /mnt/raid
# Сохранение конфигурации
mdadm --detail --scan >> /etc/mdadm.conf   # в Debian/Ubuntu: /etc/mdadm/mdadm.conf

7. LVM (Logical Volume Manager)

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

Понятий три, и они вкладываются друг в друга. Физическим томом (physical volume, PV) называют диск или раздел, отданный под управление LVM. Несколько физических томов объединяются в группу томов (volume group, VG), общий пул пространства всех дисков. Из группы, в свою очередь, выделяются логические тома (logical volume, LV), на которых и создаются файловые системы.

Порядок команд при создании:

• pvcreate /dev/sdX1 /dev/sdY1 передаёт разделы под управление LVM;
• vgcreate my_vg /dev/sdX1 /dev/sdY1 собирает из этих физических томов группу;
• lvcreate -n my_vol -L 10G my_vg выделяет из группы логический том на 10 ГБ;
• mkfs.ext4 /dev/my_vg/my_vol создаёт на нём файловую систему.

Заключение

Файловая система выбирается под ожидаемую нагрузку. ext4 остаётся разумным значением по умолчанию, XFS применяют для больших файлов, Btrfs — там, где нужны снимки, откатывающие систему к сохранённому состоянию. Схема дисков продумывается до того, как на них будут записаны данные; переразмечать массив, заполненный терабайтами, значительно дороже, чем заранее потратить полчаса на планирование. Ни RAID, ни снимки не заменяют резервную копию, хранимую в другом месте.

Задание. Собрать зеркало из двух дисков и проверить, что система переживёт отказ любого из них: «Установка Arch Linux вручную с RAID1 и UEFI».

Установка Arch Linux

Сборку системы с нуля удобнее всего рассматривать на примере Arch Linux: мастер установки в нём отсутствует, и все действия, скрытые другими дистрибутивами за полосой прогресса, выполняются вручную.

Установка осуществляется на виртуальную машину в VirtualBox, где ошибки ничего не стоят, а результат воспроизводим. Сначала система собирается в режиме Legacy BIOS, затем рассматривается вариант с зеркальным RAID-массивом, собранным из двух дисков, а в конце машина переключается на UEFI и загрузчик перенастраивается.

Создание виртуальной машины

1. В VirtualBox создаётся новая виртуальная машина.
2. Вводится имя виртуальной машины, выбирается тип операционной системы Linux и версия Arch Linux (64-bit).
3. Выделяется необходимое количество оперативной памяти (рекомендуется не менее 2 ГБ).
4. Создаётся новый виртуальный жёсткий диск в формате VDI.
5. Выделяется место на диске (рекомендуется не менее 20 ГБ).
6. В настройках виртуальной машины выбирается Legacy BIOS (или SeaBIOS).
7. Подключается ISO образ Arch Linux.

Установка Arch Linux с использованием Legacy BIOS

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

1. Запустим виртуальную машину и загрузимся с ISO образа Arch Linux.

2. С помощью cfdisk выполним разметку диска (/dev/sda). Выберем таблицу разделов GPT и создадим три раздела:

   • /dev/sda1: 1M, тип BIOS boot (код EF02)
   • /dev/sda2: 1G, тип EFI System (код EF00), то есть ESP
   • /dev/sda3: остальное пространство для корневой файловой системы

   Первый раздел выглядит лишним, однако является обязательным. На диске с MBR GRUB размещает свою вторую ступень в промежутке, оставленном после загрузочной записи, а на GPT такого промежутка нет, и grub-install --target=i386-pc откажется работать с сообщением «embedding is not possible». В раздел BIOS boot GRUB и записывает вторую ступень; файловая система на нём не создаётся, он остаётся неразмеченным.

   Второй раздел на этом этапе не потребуется: при загрузке через BIOS прошивка не имеет представления об ESP. Он заведён на будущее: в конце главы эта машина будет переключена на UEFI, и переразмечать диск не придётся.

3. Создадим файловую систему на ESP разделе.

   mkfs.fat -F32 /dev/sda2
   

4. Создадим файловую систему на корневом разделе.

   mkfs.ext4 /dev/sda3
   

5. Смонтируем корневую файловую систему.

   mount /dev/sda3 /mnt
   

6. Создадим точку монтирования и смонтируем ESP.

   mkdir /mnt/boot
   mount /dev/sda2 /mnt/boot
   

7. Установим базовую систему.

   pacstrap /mnt base linux linux-firmware
   

8. Сгенерируем файл fstab.

   genfstab -U /mnt >> /mnt/etc/fstab
   

9. Перейдём в новую систему. Команда arch-chroot подменяет корень файловой системы на /mnt, после чего все команды выполняются так, как если бы загрузка уже была произведена в устанавливаемую систему. Механика подмены корня рассматривается в главе про внутреннее устройство Linux.

   arch-chroot /mnt
   

10. Установим загрузчик GRUB.

    pacman -S grub
    grub-install --target=i386-pc /dev/sda
    grub-mkconfig -o /boot/grub/grub.cfg
    

11. Установим пароль root.

    passwd
    

12. Выйдем из chroot-окружения и размонтируем файловые системы.

    exit
    umount -R /mnt
    reboot
    

Установка Arch Linux на RAID1

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

1. Добавим виртуальной машине второй диск такого же размера и загрузимся с установочного образа Arch Linux.

2. Подготовим диски.

   cfdisk /dev/sda
   cfdisk /dev/sdb
   

   На каждом диске выберем таблицу GPT и создадим два раздела: /dev/sda1 размером 1M с типом BIOS boot (EF02) и /dev/sda2 на всё остальное с типом Linux RAID (FD00); то же самое на /dev/sdb. Раздел BIOS boot необходим по той же причине, что и в предыдущем разделе, причём на обоих дисках, иначе после отказа первого диска машина со второго не загрузится.

3. Создадим RAID1 массив.

   mdadm --create --verbose /dev/md0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2
   

4. Отформатируем RAID-массив.

   mkfs.ext4 /dev/md0
   

5. Смонтируем файловую систему.

   mount /dev/md0 /mnt
   

6. Установим базовую систему.

   pacstrap /mnt base linux linux-firmware mdadm
   

7. Сгенерируем fstab.

   genfstab -U /mnt >> /mnt/etc/fstab
   

8. Выполним chroot в новую систему.

   arch-chroot /mnt
   

9. Настроим mdadm.

   mdadm --detail --scan >> /etc/mdadm.conf
   

10. Настроим mkinitcpio:

    В файле /etc/mkinitcpio.conf необходимо добавить mdadm_udev в список HOOKS, обязательно раньше filesystems, иначе к моменту монтирования корня массив ещё не будет собран.

    HOOKS=(base udev autodetect modconf block mdadm_udev filesystems keyboard fsck)
    

11. Пересоберём начальный RAM-диск.

    mkinitcpio -P
    

12. Установим GRUB.

    pacman -S grub
    

13. Установим GRUB на оба диска.

    grub-install --target=i386-pc /dev/sda
    grub-install --target=i386-pc /dev/sdb
    

14. Создадим конфигурацию GRUB.

    grub-mkconfig -o /boot/grub/grub.cfg
    

15. Перезагрузим систему.

    exit
    umount -R /mnt
    reboot
    

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

Переключение на UEFI и настройка загрузчика

Вернёмся к машине из первой установки, размеченной на sda1, sda2 и sda3: EFI-раздел там уже заведён. Зеркало из предыдущего раздела для этого шага не подходит, поскольку ESP в нём отсутствует; связка RAID1 с UEFI собирается самостоятельно в задании.

Переустанавливать систему не потребуется: UEFI отличается от BIOS только тем, где расположен загрузчик и как прошивка его находит, поэтому достаточно разместить .efi-файл на EFI-разделе и зарегистрировать запись в NVRAM.

1. Остановим виртуальную машину.

2. В настройках виртуальной машины изменим BIOS на UEFI.

3. Запустим виртуальную машину и загрузимся с ISO образа Arch Linux.

4. Смонтируем корневую файловую систему и ESP.

   mount /dev/sda3 /mnt
   mount /dev/sda2 /mnt/boot
   arch-chroot /mnt
   

5. Установим пакеты, необходимые для загрузки с UEFI.

   pacman -S grub efibootmgr dosfstools os-prober mtools
   

6. Установим загрузчик GRUB с поддержкой UEFI.

   grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=GRUB
   grub-mkconfig -o /boot/grub/grub.cfg
   efibootmgr -v
   

В выводе efibootmgr -v должна появиться запись GRUB. Если она отсутствует, необходимо убедиться, что раздел с .efi-файлом смонтирован в /boot и отформатирован в FAT32.

Задание. Установка повторяется самостоятельно, но с зеркалированием диска и загрузкой через UEFI: «Установка Arch Linux вручную с RAID1 и UEFI».

Внутреннее устройство Linux

Без понимания того, что происходит внутри системы, первый же зависший расчёт или необъяснимо медленный ввод-вывод превращается в гадание.

Слайды к главе. Материал главы изложен также в лекции «Внутренности Linux» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Значение внутреннего устройства

Знание внутреннего устройства необходимо в четырёх ситуациях. Когда расчёт завис или исчерпал всю память, требуется ставить диагноз, а не перезапускать наугад. Если программа работает медленнее ожидаемого, необходимо знать, куда смотреть. При написании кода полезно представлять, во что обходится каждый системный вызов, сделанный в цикле. Наконец, вся современная облачная инфраструктура выросла из механизмов ядра Linux, поэтому без них разобраться в ней невозможно.

Облаком называют чужие компьютеры, расположенные в другом месте. Те же процессы, та же память, та же сеть, только в удалённом дата-центре и с чужим счётом за электричество.

Практическая ценность глубоких знаний

Быстрая диагностика проблем

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

# Вместо случайного тыкания
strace -p <pid>                    # что делает процесс?
perf record -g <command>          # где тратится время?
cat /proc/<pid>/status            # в каком состоянии?

Служба периодически «зависала» на несколько минут и восстанавливалась сама; в top при этом не наблюдалось ни загрузки процессора, ни повышенного расхода памяти. Разгадка заключалась в состоянии процесса: ps показывал D, непрерываемое ожидание ввода-вывода. Служба писала на сетевой диск NFS, тот время от времени переставал отвечать, и процесс, пробуждаемый лишь ответом, ждал. Проблема устранялась не в коде, а тайм-аутами монтирования и числом попыток, разрешённых на повтор.

Эффективное программирование

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

• системный вызов стоит около тысячи тактов процессора;
• переключение контекста, происходящее между процессами, стоит от тысячи до десяти тысяч тактов;
• промах по странице памяти занимает доли микросекунды, если страница уже загружена в память, и от сотен микросекунд на NVMe до единиц миллисекунд на диске, если её приходится читать.

Обращаться к ядру в тесном цикле нецелесообразно: данные накапливаются в буфере и передаются разом. Разница между write на каждое число и write на мегабайтный буфер измеряется порядками.

Облачные технологии

Контейнеры, оркестраторы, бессерверные вычисления представляют собой надстройки над механизмами ядра, которым посвящена глава. Docker использует те же cgroups и пространства имён, только удобно упакованные. Kubernetes управляет ими же, но в масштабе кластера из сотен машин, работающего годами. AWS Lambda — та же изоляция, доведённая до очень быстрого запуска.

1. Процессы

Детальное понимание процессов

Процесс как учётная единица

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

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

Ядро знает о процессе следующее: идентификаторы самого процесса и его родителя (PID и PPID), от какого пользователя и группы он запущен (UID и GID), с каким приоритетом его планировать, в каком состоянии он сейчас находится и сколько ресурсов уже израсходовано. Всё это расположено в файловой системе /proc, открытой для чтения.

Структура процесса в ядре

// Упрощенная task_struct (include/linux/sched.h)
struct task_struct {
    volatile long state;                    // состояние процесса
    void *stack;                           // указатель на стек
    struct mm_struct *mm;                  // память процесса
    struct files_struct *files;            // открытые файлы
    struct signal_struct *signal;          // сигналы
    // ... сотни полей
};

Всё перечисленное ядро предоставляет наружу через файловую систему /proc, позволяющую исследовать любой работающий процесс:

# Анализ конкретного процесса
ls -la /proc/1234/
cat /proc/1234/maps    # память процесса
cat /proc/1234/status  # состояние и лимиты
ls /proc/1234/fd/      # открытые файлы

Создание процессов: fork() и exec()

Механизм Copy-on-Write (CoW)

Системный вызов fork(), создающий копию текущего процесса, в наивной реализации копировал всю память родителя. Для расчёта, занявшего десять гигабайт, это означало те же десять гигабайт, скопированных впустую, притом что сразу после fork() дочерний процесс обычно вызывает exec() и вся скопированная память немедленно уничтожается.

Отсюда copy-on-write, копирование при записи. При fork() память не копируется. Страницы помечаются как доступные только для чтения, и оба процесса читают их из одного и того же физического места. Настоящая копия создаётся лениво, в тот момент, когда один из двух процессов пытается в страницу записать, и только для затронутой страницы. В типичном случае «породить процесс и сразу запустить в нём другую программу» копировать почти ничего не приходится.

pid_t pid = fork();
if (pid == 0) {
    // Дочерний процесс
    // Страницы памяти разделяются до первой записи
    execve("/bin/ls", args, env);
} else {
    // Родительский процесс
    waitpid(pid, &status, 0);
}

Потоки и процессы

Архитектурные различия

Практические сценарии использования

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

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

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

Межпроцессное взаимодействие (IPC)

Сигналы как асинхронные уведомления

// Отправка сигнала
kill(pid, SIGTERM);

// Обработка сигнала
void handler(int sig) {
    // Асинхронно! Осторожно с shared state
}
signal(SIGTERM, handler);

Обработчик прерывает выполнение программы в произвольной точке, поэтому вызывать из него разрешено далеко не всё. Если сигнал придёт в середине malloc, повторный malloc из обработчика застанет кучу в противоречивом состоянии и окончательно её повредит. Безопасным является только список функций, оговорённый стандартом. Их называют async-signal-safe, и printf в него не входит. Обычная практика состоит в том, чтобы выставить в обработчике флаг и сразу вернуться, а содержательную работу выполнить в основном цикле программы.

SIGHUP получают процессы, привязанные к терминалу, когда сессия закрывается, и по умолчанию он их завершает. Поэтому долгий расчёт, запущенный по ssh, завершается вместе с разорванным соединением. Пережить закрытие сессии процесс может, если его отвязать от терминала: для этого служат nohup, setsid и встроенная в оболочку команда disown, а также screen и tmux из главы про инструменты Linux.

Каналы как односторонняя связь

# Неименованные каналы
ls -la | grep ".txt" | wc -l

# Именованные каналы (FIFO)
mkfifo mypipe
echo "data" > mypipe &
cat mypipe

Канал представляет собой буфер, выделенный в памяти ядра, по умолчанию около 64 КБ. Пока в буфере остаётся место, пишущая сторона не задерживается; когда буфер заполнен, write блокируется, пока читающая сторона не заберёт накопленное. Так работает конвейер команда | команда. Быстрый производитель, ограниченный медленным потребителем, сам замедляется до его скорости, и никакой явной синхронизации писать не приходится.

Разделяемая память и максимальная производительность

// Создание shared memory
int shm_id = shmget(key, size, IPC_CREAT | 0666);
void *ptr = shmat(shm_id, NULL, 0);

// Использование
memcpy(ptr, data, data_size);

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

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

Семафоры и координация доступа

// Бинарный семафор (мьютекс)
sem_wait(&mutex);
// Критическая секция
sem_post(&mutex);

На практике достаточно двух видов семафоров. Двоичный принимает значения 0 и 1 и работает как мьютекс, защищающий критическую секцию. Считающий хранит целое число и ограничивает число пользователей, одновременно допущенных к ресурсу; например, разрешает читать общий файл не более чем четырём потокам сразу.

Состояния процессов: полный цикл жизни

Детали каждого состояния

Основные буквы состояния в выводе ps:

R (running / runnable) означает, что процесс либо выполняется в настоящий момент, либо стоит в очереди планировщика и готов выполняться. Ограничивает его только доступность процессорного времени. Если расчёт долго находится в R, он считает.

S (interruptible sleep) означает, что процесс чего-то ожидает: завершения ввода-вывода, семафора, сигнала. Такое ожидание прерывается сигналом, то есть процесс, находящийся в нём, нормально завершается по kill. Для программ, больше ожидающих, чем считающих, S является обычным рабочим состоянием.

D (uninterruptible sleep) описывает ожидание внутри ядра, которое нельзя прервать: чаще всего ввода-вывода блочного устройства или сетевой файловой системы, реже — некоторых блокировок ядра; ожидание данных из сетевого сокета, напротив, относится к состоянию S. Оно не прерывается сигналом, включая kill -9. С ним сталкиваются, когда процесс «завис намертво» и не завершается ничем; чаще всего причиной является отказавший сетевой диск, смонтированный по NFS. Разбираться в таком случае приходится с устройством.

T (stopped) показывает, что процесс приостановлен сигналом SIGSTOP или SIGTSTP и продолжится по SIGCONT. Так работает нажатие Ctrl+Z в оболочке, и так же останавливают процесс отладчики, устанавливающие точку останова.

Z (zombie) означает, что процесс уже завершился, но родитель не забрал его код возврата. Ресурсы освобождены, осталась одна запись в таблице процессов ради кода возврата. Завершить зомби нельзя, он и так завершён; запись исчезнет, когда родитель вызовет wait, а если родитель этого не делает, то после его завершения. Осиротевших зомби забирает процесс init.

Практический мониторинг

Сводку по состояниям всех процессов система выдаёт одной строкой; с неё удобно начинать разбор: она сразу показывает, есть ли в системе процессы, застрявшие в D, или накопившиеся зомби.

# Понимание состояния процессов
ps aux | awk '{print $8}' | sort | uniq -c

# Поиск проблемных процессов
# Процессы в D состоянии
ps aux | awk '$8=="D" {print $0}'

# Zombie процессы
ps aux | awk '$8=="Z" {print $0}'

2. Планировщик

Эволюция планировщиков Linux

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

O(N) планировщик (по 2.4 включительно)

// Псевдокод старого планировщика
for (each task in system) {
    calculate_goodness(task);
    if (goodness > max_goodness) {
        next_task = task;
        max_goodness = goodness;
    }
}

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

O(1) планировщик (2.6.0–2.6.22)

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

CFS (Completely Fair Scheduler) (2.6.23+)

// Основан на красно-чёрных деревьях
struct rb_root_cached {
    struct rb_root rb_root;
    struct rb_node *rb_leftmost;
};

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

Приоритеты и политики планирования

Политики реального времени

Для задач, где важна не общая пропускная способность, а гарантированное время реакции (управление установкой, сбор данных с жёстким тактом), в ядре предусмотрены две политики реального времени.

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

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

Обычные политики

Всё остальное, а это практически все процессы, включая пользовательский расчёт, работает под политикой SCHED_NORMAL (она же SCHED_OTHER). Жёстких гарантий она не даёт, но и никого не лишает процессорного времени полностью. Приоритет плавающий, планировщик корректирует его сам. Процессу, который много спит в ожидании ввода, например реагирует на нажатия клавиш, достаётся небольшая прибавка, удерживающая систему отзывчивой. Процессу, который непрерывно считает, долю слегка урезают: своё он доберёт, пока остальные ждут.

Значения nice и приоритеты

# Установка nice значения
nice -n 10 ./long_running_task    # низкий приоритет
nice -n -20 ./critical_task       # высокий приоритет

# Изменение running процесса
renice -n 5 -p 1234

Шкала nice идёт от -20 до +19. Чем больше значение, тем ниже приоритет: процесс «вежливее» и охотнее уступает. Понижать себе приоритет может любой пользователь, а повышать, то есть уходить в отрицательные значения, разрешено только root.

CFS: внутреннее устройство

Ключевые концепции

Поведение планировщика определяется несколькими величинами.

Виртуальное время выполнения (vruntime) — счётчик, растущий у каждого процесса, пока тот занимает процессор. Скорость роста зависит от приоритета: у высокоприоритетного медленнее, у низкоприоритетного быстрее. Планировщик всегда выбирает процесс с наименьшим vruntime: «справедливым» считается тот, кому досталось меньше всех. Значение nice влияет на скорость накопления этого счётчика.

Целевой задержкой (target latency) называют срок, за который каждый готовый к выполнению процесс должен успеть получить процессор хотя бы раз. По умолчанию это 6 мс, умноженные на поправку по числу процессоров: единица плюс двоичный логарифм их числа, причём учитываются не более восьми. Получается от 6 мс на одном ядре до 24 мс на восьми и более. За отзывчивость интерфейса платят более частыми переключениями.

Минимальный квант (minimal granularity) задаёт нижнюю границу доли процесса. Готовых процессов бывает очень много, и честное деление целевой задержки на всех дало бы каждому доли микросекунды: система занималась бы одними переключениями. Поэтому квант не делают короче 0,75 мс с той же поправкой по числу процессоров, слегка нарушая справедливость.

Реализация на красно-чёрных деревьях

// Вставка процесса в дерево
struct sched_entity {
    struct rb_node run_node;
    u64 vruntime;
    // ...
};

// Быстрый поиск процесса с минимальным vruntime
struct task_struct *pick_next_task(struct rq *rq) {
    struct rb_node *left = rb_first_cached(&rq->tasks_timeline);
    return rb_entry(left, struct task_struct, se.run_node);
}

Вставка и удаление обходятся в O(log N), а процесс с наименьшим vruntime всегда находится в самом левом узле, причём указатель на него ядро хранит отдельно и обновляет по ходу работы, поэтому самая частая операция планировщика, выбор следующего процесса, выполняется за постоянное время.

Управление планировщиком на практике

Привязка к ядрам

# Привязка процесса к конкретным ядрам
taskset -c 0,1 ./application

# Просмотр текущей маски
taskset -p 1234

# Запуск с распределением по ядрам
numactl --cpunodebind=0,1 --membind=0,1 ./app

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

Настройка планировщика

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

На ядрах до 5.13 параметры располагались в /proc/sys/kernel/:

cat /proc/sys/kernel/sched_min_granularity_ns
cat /proc/sys/kernel/sched_latency_ns
echo 10000000 > /proc/sys/kernel/sched_latency_ns

В 5.13 они были вынесены из sysctl в отладочную файловую систему с сохранением прежних имён. Такой вариант ещё встречается на завершающих поддержку LTS наподобие Ubuntu 22.04 с исходным ядром 5.15:

cat /sys/kernel/debug/sched/min_granularity_ns
cat /sys/kernel/debug/sched/latency_ns

С 6.6 CFS заменён на EEVDF, и параметры, названные под старый планировщик, исчезли вместе с ним. С этим случаем столкнётся большинство читателей: в Ubuntu 24.04 установлено ядро 6.8, в Debian 13 — 6.12, оба с EEVDF, и старых имён в отладочной файловой системе там нет. Ближайший по смыслу параметр называется base_slice_ns:

cat /sys/kernel/debug/sched/base_slice_ns

Какой из трёх случаев имеет место, показывает uname -r.

Мониторинг планировщика

При подозрении, что процесс не получает процессорного времени, лучше обращаться не к top, а к статистике планировщика. Там видно, сколько раз процесс вытесняли и сколько он в сумме простоял в очереди.

# Статистика переключений
cat /proc/1234/sched

# Очереди выполнения
cat /proc/sched_debug

# Профилирование
perf sched record ./application
perf sched latency

3. Прерывания

Архитектура прерываний в x86/x64

Аппаратные прерывания

Прерыванием устройство сообщает процессору о готовности и требует обработки. Источников в обычной машине немного: системные таймеры, сетевые карты, дисковые контроллеры и устройства, подключённые к шине USB. В лаборатории к ним добавляется всё, что установлено в крейте: АЦП, счётчики, генераторы задержек.

Драйвер регистрирует обработчик на номер прерывания, и ядро вызывает его каждый раз, когда устройство подаёт сигнал:

// Регистрация обработчика
request_irq(IRQ_NUMBER, handler, flags, name, dev);

// Обработчик прерывания
static irqreturn_t my_handler(int irq, void *dev_id) {
    // Быстрая обработка
    return IRQ_HANDLED;
}

Исключения процессора

Процессор прерывает и сам себя, встретив ситуацию, с которой не справляется в одиночку. Такие события делятся на три вида по тому, чем они заканчиваются. Отказ (fault) исправим: типичный пример — обращение к странице, отсутствующей в физической памяти; ядро подгружает её и повторяет ту же инструкцию. Ловушка (trap) вызывается намеренно, так работают точки останова в отладчике, и выполнение продолжается со следующей инструкции. Авария (abort) не исправляется: состояние потеряно безвозвратно.

Обработка прерываний: верхняя и нижняя половины

Верхняя половина

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

// Типичный upper half
irqreturn_t eth_interrupt(int irq, void *dev_id) {
    struct net_device *dev = dev_id;
    disable_irq_nosync(dev->irq);
    schedule_work(&dev->tx_work);
    return IRQ_HANDLED;
}

Нижняя половина

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

SoftIRQ — самый быстрый механизм, но встроенный в ядро статически. Набор мягких прерываний фиксирован (сеть, блочные устройства), и добавить собственное невозможно. Tasklet создаётся динамически и потому подходит для драйверов, написанных под собственное оборудование, но один и тот же tasklet никогда не выполняется на двух ядрах одновременно, что упрощает разработку и ограничивает масштабирование. Очередь работ (work queue) выполняется в контексте обычного процесса ядра, поэтому ей разрешено засыпать и выполнять блокирующие вызовы. За это платят задержкой, и очереди применяют для длительной работы.

// Work queue пример
DECLARE_WORK(my_work, my_work_function);

void my_work_function(struct work_struct *work) {
    // Медленная обработка
    process_packets();
    enable_irq(dev->irq);
}

Практическая работа с прерываниями

Мониторинг прерываний

# Статистика прерываний
cat /proc/interrupts

# Распределение прерываний по CPU
cat /proc/irq/*/smp_affinity

# Изменение привязки прерываний
echo 2 > /proc/irq/24/smp_affinity

Оптимизация обработки

Когда прерываний становится слишком много (на быстрой сетевой карте или скоростном АЦП их десятки тысяч в секунду), обработку настраивают.

Прерывания распределяют между ядрами процессора. По умолчанию все они могут поступать на нулевое ядро, которое перегружается, пока остальные простаивают. Вместо устаревшего механизма прерываний по выделенной линии используют MSI, где устройство сообщает о событии записью в память; это снимает ограничение на число линий и упрощает распределение. Для сетевых карт подбирают длину очередей: слишком короткая теряет пакеты на всплесках, слишком длинная увеличивает задержку. Включают объединение прерываний (coalescing): устройству разрешают накопить несколько событий и сообщить о накопленном разом, при этом число прерываний падает в разы ценой небольшой задержки.

4. Системные вызовы

Механизм системных вызовов

Переключение между пространствами

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

Пользовательское пространство → Пространство ядра:

; x86-64 системный вызов
mov rax, 1      ; номер syscall (write)
mov rdi, 1      ; fd (stdout)
mov rsi, buffer ; буфер
mov rdx, count  ; размер
syscall         ; переход в ядро

За инструкцией syscall стоят шесть шагов. Процессор сохраняет контекст пользовательского кода, то есть регистры и указатель, хранящий адрес инструкции, и переходит в режим ядра. Ядро проверяет переданные параметры, поскольку доверять пользовательской программе нельзя; адрес буфера может указывать куда угодно. Затем выполняется собственно операция, результат записывается туда, где его ожидает программа, и сохранённый контекст восстанавливается.

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

Таблица системных вызовов

// Определение syscall (fs/read_write.c)
SYSCALL_DEFINE3(write, unsigned int, fd, const char __user *, buf,
                size_t, count)
{
    struct fd f = fdget_pos(fd);
    // ... обработка
    return ret;
}

Дескриптор, полученный от программы, напрямую не используется, а сначала преобразуется в проверенный объект ядра. Так устроен любой системный вызов: ни одному числу из пользовательского пространства ядро не доверяет.

Безопасность системных вызовов

Проверки доступа

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

// Проверка указателей из userspace
if (copy_from_user(kernel_buf, user_buf, size))
    return -EFAULT;

// Проверка прав доступа
if (!file_permission(file, MAY_READ))
    return -EPERM;

Права по возможностям (capabilities)

Исторически права проверялись просто: root (UID 0) может всё, остальные почти ничего. Программе, которой требуется одна привилегия, например открыть сетевой сокет на порту ниже 1024, приходилось выдавать полномочия root целиком. Современное ядро дробит права root на несколько десятков отдельных возможностей (capabilities) и проверяет конкретную из них.

// Вместо проверки UID == 0
if (!capable(CAP_SYS_ADMIN))
    return -EPERM;

Производительность системных вызовов

Измерение стоимости

#include <sys/time.h>

struct timeval start, end;
gettimeofday(&start, NULL);
// системный вызов
gettimeofday(&end, NULL);

long microseconds = (end.tv_sec - start.tv_sec) * 1000000 
                  + (end.tv_usec - start.tv_usec);

Порядки величин необходимо помнить. Простой системный вызов наподобие getpid обходится в 0.1–1 микросекунду. Вызовы с вводом-выводом занимают от микросекунды до миллисекунды; разброс зависит от того, попал ли запрос в кеш или был направлен на диск. Переключение контекста между процессами стоит 1–10 микросекунд.

Обычное обращение в оперативную память занимает около сотни наносекунд. Отсюда следует правило: в тесном цикле системным вызовам не место; один write на каждое число превратит расчёт в сплошное ожидание.

Оптимизация

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

Вызовы объединяют, заменяя десять write подряд одним writev, принимающим сразу список буферов. Файл отображают в память через mmap и далее работают с ним как с обычным массивом, без read и write; для больших файлов данных это является лучшим вариантом. Лишние вызовы устраняют: типичный случай — проверка существования файла перед открытием, хотя открытие и так вернёт ошибку. Для нескольких самых частых вызовов наподобие gettimeofday в Linux предусмотрен vDSO — фрагмент кода ядра, отображённый в память процесса, благодаря чему переключаться в режим ядра не приходится.

5. Память процесса

Виртуальная память: полная картина

Карта адресного пространства

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

0x0000000000000000 ┌──────────────────────┐
                   │   Зарезервировано    │
                   │   (NULL-ptr guard)   │
0x0000000000400000 ├──────────────────────┤
                   │         Text         │
                   │   (код программы)    │
0x0000000000600000 ├──────────────────────┤
                   │         Data         │
                   │        (init)        │
0x0000000000601000 ├──────────────────────┤
                   │         BSS          │
                   │       (uninit)       │
0x0000000000800000 ├──────────────────────┤
                   │         Heap         │
                   │    (динамическая)    │
                   │          ↓           │
0x00007ffff0000000 ├──────────────────────┤
                   │     MMAP region      │
                   │     (библиотеки,     │
                   │     shared mem)      │
0x00007ffff7a00000 ├──────────────────────┤
                   │        Stack         │
                   │   (автоматические)   │
                   │          ↑           │
0x00007fffffffffff ├──────────────────────┤
                   │    неканоническая    │
                   │         дыра         │
0xffff800000000000 ├──────────────────────┤
                   │     Kernel space     │
                   │     (недоступно)     │
0xffffffffffffffff └──────────────────────┘

Управление памятью на практике

Анализ памяти процесса

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

# Детальная информация о памяти
pmap -XX 1234

# Статистика памяти
cat /proc/1234/smaps

# Page faults
ps -o min_flt,maj_flt,cmd -p 1234

Виды промахов по странице

Промахи по страницам бывают двух видов, и различаются они на три порядка по стоимости.

Малый промах (minor fault) происходит, когда нужная страница уже находится в физической памяти, но пока не прописана в таблицах страниц процесса, например разделяется с соседним процессом, читающим то же самое, или только что выделена. Ядру достаточно обновить таблицы, и обходится это дёшево.

Большой промах (major fault) означает, что страницы в памяти нет и её необходимо читать с диска. Это миллисекунды вместо микросекунд. Если ps или top показывают, что расчёт набирает большие промахи тысячами, значит, ему не хватает выделенной памяти и система перешла в подкачку. Оптимизировать код в этот момент бессмысленно, необходимо разбираться с памятью.

Проблемы с памятью и решения

Нехватка памяти и OOM killer

Когда память в системе заканчивается и освободить её больше нечем, ядро не возвращает ошибку, а выбирает жертву и завершает её. OOM killer работает в три шага. Ядро фиксирует нехватку памяти, начисляет каждому процессу «балл вредности» (главным образом по объёму занятой памяти) и завершает процесс с наибольшим баллом. Обычно это пользовательский расчёт, самый требовательный к памяти в системе.

Процесс исчезает без сообщения об ошибке, а в выводе dmesg остаётся строка Out of memory: Killed process. Балл корректируют вручную, защищая критичную службу или назначая заведомую жертву.

Управление OOM:

# Настройка политики OOM
echo -1000 > /proc/1234/oom_score_adj    # защитить процесс
echo 1000 > /proc/1234/oom_score_adj     # первый кандидат

# Ручной вызов OOM killer: НЕ на рабочей машине —
# ядро прямо сейчас убьёт живой процесс, выбрав его само.
# kernel.sysrq ограничивает только клавиатуру: root вызывает
# через /proc/sysrq-trigger любые функции SysRq
echo f > /proc/sysrq-trigger

Управление подкачкой

Подкачка является не запасной памятью, а способом выгрузить на диск страницы, давно не использовавшиеся. Расчётному узлу она скорее вредит: если рабочий набор перестал помещаться в оперативную память, подкачка замедлит всё в сотни раз, и машина будет выглядеть зависшей. Насколько охотно ядро выгружает страницы, задаёт параметр swappiness, установленный по умолчанию в 60; на сервере его снижают, на настольной машине оставляют без изменений.

# Мониторинг swap
swapon --show
free -h

# Настройка swappiness
echo 10 > /proc/sys/vm/swappiness    # меньше swap (сервер)
echo 60 > /proc/sys/vm/swappiness    # больше swap (десктоп)

Настройка под NUMA

На машинах с несколькими процессорными сокетами память разделена между ними, и обращение к «чужой» памяти, подключённой к соседнему сокету, обходится заметно дороже, чем к своей. Такая архитектура называется NUMA. Если расчёт занимает весь узел, ядро обычно распределяет всё разумно само. Когда на узле выполняется несколько задач одновременно, каждую необходимо привязывать к своему сокету вместе с её памятью, иначе они будут обращаться к памяти через шину между сокетами.

# Информация о NUMA
numactl --hardware

# Запуск с учетом NUMA
numactl --membind=0 --cpunodebind=0 ./application

# Статистика NUMA
cat /proc/1234/numa_maps

6. Изоляция

На рассматриваемых ниже механизмах ядра основан Docker из следующей главы.

Эволюция изоляции в Linux

От chroot до контейнеров

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

• 1979, chroot в UNIX: процессу подменяют корень файловой системы;
• 2000, FreeBSD Jails: к файловой системе добавляется изоляция процессов и сети;
• 2001, Linux-VServer и 2004, Solaris Zones: те же идеи в других системах;
• 2008, LXC: в ядре Linux появляются пространства имён и cgroups, то есть всё необходимое;
• 2013, Docker: удобная упаковка поверх готовых механизмов ядра;
• 2014, Kubernetes: управление контейнерами в масштабе кластера.

Механизмы ядра были готовы за пять лет до Docker; революция 2013 года произошла в удобстве: появился простой способ описать образ одним файлом и передать его другому человеку.

Cgroups: управление ресурсами

Иерархия cgroups v2

Cgroups отвечают за вторую половину изоляции, не за то, что процесс видит, а за то, сколько он может потребить. Устроены они как дерево каталогов в /sys/fs/cgroup, где каждый каталог представляет группу процессов, а файлы внутри неё задают лимиты и хранят накопленные счётчики. Ограничение, установленное на узел дерева, действует на всё поддерево целиком.

/sys/fs/cgroup/
├── system.slice/          # системные службы
│   ├── ssh.service
│   └── docker.service
├── user.slice/            # пользовательские процессы
│   ├── user-1000.slice
│   └── user-1001.slice
├── kubepods.slice/        # Kubernetes pods
│   ├── pod1/
│   └── pod2/
└── cgroup.controllers     # доступные контроллеры

Контроллеры ресурсов

За каждый вид ресурса отвечает свой контроллер, а лимит устанавливается записью в файл.

Перед тем как устанавливать лимиты, группу необходимо создать и разрешить в ней нужные контроллеры, поскольку родитель передаёт их потомкам явно:

mkdir /sys/fs/cgroup/mygroup
echo "+cpu +memory +io" > /sys/fs/cgroup/cgroup.subtree_control

Без этих двух строк ни одна команда ниже не выполнится.

CPU:

# Ограничение CPU
echo "200000 1000000" > /sys/fs/cgroup/mygroup/cpu.max
# 200ms из каждых 1000ms

# CPU shares
echo 512 > /sys/fs/cgroup/mygroup/cpu.weight

Память:

# Лимит памяти
echo 1G > /sys/fs/cgroup/mygroup/memory.max

# SWAP лимит
echo 2G > /sys/fs/cgroup/mygroup/memory.swap.max

# убивать всю группу целиком, а не один процесс
echo 1 > /sys/fs/cgroup/mygroup/memory.oom.group

I/O:

# Ограничение дискового I/O
echo "8:0 rbps=1048576 wbps=1048576" > /sys/fs/cgroup/mygroup/io.max

Пространства имён: изоляция представлений

Виды пространств имён

Пространства имён отвечают за первую половину изоляции, подменяя процессу представление о системе. В своём PID-пространстве процесс видит себя первым номером и не подозревает о существовании остальных; в своём сетевом располагает собственными интерфейсами и портами. Видов пространств восемь, каждое подменяет что-то одно.

Пространства имён на практике

Команда unshare создаёт новые пространства имён и запускает в них процесс:

# Создание namespace и запуск процесса
sudo unshare --fork --pid --mount-proc bash

# В новом namespace:
ps aux    # видит только свои процессы
mount     # видит только свои mount points

До контейнера остаётся один шаг: предоставить процессу собственный корень файловой системы. Сверх этого Docker упаковывает корень в образ с метаданными и позволяет его скачивать и распространять.

# Создание root filesystem
mkdir /mycontainer
debootstrap stable /mycontainer

# Запуск в изоляции
unshare --fork --pid --mount-proc --net --uts --root=/mycontainer /bin/bash

# В контейнере:
hostname mycontainer
ip link set lo up

Заключение

При странном поведении программы правильнее не гадать, а запросить у системы, чем она занята. Если процесс завис, рассматривается его состояние; если расчёт замедлился, рассматриваются промахи по страницам и переключения контекста; если время уходит непонятно на что, рассматриваются системные вызовы, сделанные за секунду. Ядро сообщает о себе через /proc, /sys и perf.

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

Задания. Наблюдение за процессами и сигналами на практике: «Работа с долгоиграющими процессами». strace и perf, здесь только названные, потребуются в задании «Настройка окружения и работа с утилитами».

Docker

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

Слайды к главе. Выпуск и откат приложения в контейнере, а также автоматический перезапуск после сбоя показаны в лекции «Жизненный цикл ПО» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

«У меня на машине работает»

Типичная ситуация выглядит следующим образом. Скрипт обработки данных, полученных на эксперименте, работает на ноутбуке автора, а при отправке коллеге завершается с ImportError. При запуске на кластере обнаруживается Python 3.8 вместо 3.12, системный numpy собран без нужных флагов, а права на установку пакетов есть только у администратора, находящегося в отпуске. Через два года рецензент просит воспроизвести график, напечатанный в статье, а автор уже не помнит версий библиотек, использовавшихся в то время.

Для физики это удар по воспроизводимости. Численный результат, не поддающийся повторению, стоит немногим больше, чем результат, которого нет. Виртуальные окружения и requirements.txt решают проблему частично: они фиксируют версии установленных Python-пакетов, но не версию самого Python, не системные библиотеки (BLAS, LAPACK, HDF5, компиляторы), не переменные окружения и не операционную систему. Создание виртуальных окружений и их наполнение рассматриваются в главе «От скрипта к приложению».

Docker упаковывает приложение вместе со всем его окружением, с интерпретатором, библиотеками, системными зависимостями и настройками, в единый образ. Собранный образ запускается одинаково на ноутбуке автора, на машине коллеги и на сервере в лаборатории, если у них одна архитектура процессора: контейнер использует ядро и процессор хоста, поэтому для машин на x86-64 и на ARM собирают многоплатформенный образ (docker buildx build --platform linux/amd64,linux/arm64).

Контейнеры vs виртуальные машины

Контейнер не является виртуальной машиной. Виртуальная машина эмулирует целый компьютер, несущий внутри полноценную гостевую операционную систему со своим ядром, а гипервизор транслирует её обращения к аппаратуре. Изоляция надёжная, но дорогая: каждая ВМ занимает гигабайты и стартует десятки секунд.

Контейнер представляет собой обычный процесс операционной системы, к которому ядро Linux применило два механизма. Namespaces (пространства имён) изолируют то, что процесс видит: у контейнера свои дерево процессов, сетевые интерфейсы и файловая система, и он считает себя единственным в системе. Cgroups (control groups) ограничивают то, что процесс потребляет, то есть отведённые ему память, процессорное время и дисковый ввод-вывод. Ядро при этом остаётся общим для всех контейнеров и хоста, поэтому контейнер стартует за доли секунды, а образ занимает от десятков до сотен мегабайт вместо гигабайт, занимаемых виртуальной машиной. Платой является несколько более слабая изоляция, чем у ВМ, что существенно для запуска чужого недоверенного кода и несущественно для упаковки собственных расчётов. Пространства имён и контрольные группы рассмотрены в предыдущей главе.

На macOS и Windows нативные Linux-контейнеры невозможны, поэтому Docker Desktop поддерживает лёгкую виртуальную машину с Linux, внутри которой работают контейнеры.

Образы и контейнеры

Существуют два центральных понятия:

• Образ (image) — неизменяемый шаблон: файловая система с установленными в неё программами плюс метаданные (какую команду запускать, какие порты открывать). В терминах программирования образ соответствует классу.
• Контейнер (container) — запущенный экземпляр образа, процесс со своим состоянием, объект этого класса. Из одного образа можно запустить произвольное число контейнеров.

Готовые образы скачиваются из реестра, по умолчанию из Docker Hub.

# скачать официальный образ Python 3.12 (slim — урезанный, без лишнего)
docker pull python:3.12-slim

# список локально скачанных образов
docker images

Запись python:3.12-slim читается как «репозиторий:тег», где тег означает версию. Если тег не указан, подставляется latest, и образ под этим тегом сегодня и через год окажется разным, а требуется воспроизводимость. То же относится к 3.12-slim: тег переносится на каждый новый выпуск Python 3.12.x и базового Debian. Неизменяемой ссылкой служит дайджест, python:3.12-slim@sha256:…; его показывает docker images --digests.

Запуск контейнера осуществляется следующим образом:

# запустить контейнер и выполнить в нём одну команду
docker run python:3.12-slim python -c "print('hello from container')"

# интерактивный запуск: -i — пробросить stdin, -t — выделить терминал
# получаем REPL питона внутри контейнера
docker run -it python:3.12-slim python

# а так можно попасть в шелл контейнера и осмотреться
docker run -it python:3.12-slim bash

# --rm — удалить контейнер сразу после завершения (не копить мусор)
docker run --rm -it python:3.12-slim bash

Внутри контейнера команда ls / показывает чужую файловую систему, pip install устанавливает пакет внутри контейнера, и после его удаления всё исчезает. Контейнеры эфемерны: всё ценное должно находиться либо в образе, либо в примонтированных томах (о них ниже).

Управление контейнерами:

docker ps               # запущенные контейнеры
docker ps -a            # все, включая остановленные
docker stop <id|имя>    # мягко остановить контейнер
docker rm <id|имя>      # удалить остановленный контейнер
docker rmi <образ>      # удалить образ
docker logs <id|имя>    # посмотреть, что контейнер писал в stdout/stderr

Вместо полного идентификатора можно указывать первые несколько символов или имя, выданное контейнеру самим Docker (или заданное через --name).

Проброс портов и томов

Контейнер изолирован, в том числе по сети и по файлам; изоляция нарушается в нужных местах двумя флагами.

Порты, -p хост:контейнер. Сервис внутри контейнера слушает свой порт, и снаружи он недоступен, пока порт не проброшен на хост.

Тома, -v путь_на_хосте:путь_в_контейнере. Каталог хоста монтируется внутрь контейнера, файлы видны с обеих сторон, а полученные результаты сохраняются после удаления контейнера.

Пример: Jupyter, запущенный в контейнере без единого pip install на собственной машине.

# jupyter/scipy-notebook — готовый образ с numpy, scipy, pandas, matplotlib
# -p 8888:8888          порт 8888 хоста -> порт 8888 контейнера
# -v ...:/home/jovyan/work   текущий каталог -> каталог work внутри контейнера
# тег фиксируем ради воспроизводимости, реестр указываем явно:
# образы jupyter в конце 2023 года переехали с Docker Hub на quay.io
docker run --rm \
    -p 8888:8888 \
    -v "$(pwd)":/home/jovyan/work \
    quay.io/jupyter/scipy-notebook:2024-05-27

В браузере открывается http://localhost:8888 по ссылке с токеном, выведенной контейнером в журнал, и работа ведётся в блокнотах, находящихся в текущем каталоге хоста. После удаления контейнера блокноты остаются, а окружение исчезает.

Dockerfile: свой образ для научного проекта

Расчётный код требует своего набора зависимостей; рецепт сборки образа описывается в файле Dockerfile. Пусть имеется проект моделирования динамики пучка.

beam-simulation/
├── Dockerfile
├── requirements.txt      # numpy, scipy, matplotlib с версиями
├── simulate.py           # основной расчёт
└── beamlib/              # свои модули

Содержимое requirements.txt:

numpy==2.1.3
scipy==1.14.1
matplotlib==3.9.2

Dockerfile:

# Базовый образ: официальный Python, slim-вариант без лишних пакетов.
# Версия Python зафиксирована тегом; точный образ закрепляет дайджест.
FROM python:3.12-slim

# Рабочий каталог внутри образа; все следующие команды выполняются в нём.
# Если каталога нет, он будет создан.
WORKDIR /app

# Сначала копируем ТОЛЬКО файл с зависимостями...
COPY requirements.txt .

# ...и устанавливаем их. --no-cache-dir не хранит кеш pip в образе,
# образ получается меньше.
RUN pip install --no-cache-dir -r requirements.txt

# Только теперь копируем весь остальной код проекта.
COPY . .

# Команда по умолчанию при запуске контейнера.
# Форма со скобками (exec form) запускает процесс напрямую, без оболочки.
CMD ["python", "simulate.py"]

Рассмотрим инструкции:

• FROM задаёт базовый образ. Всё, что содержится в python:3.12-slim (Debian, Python, pip), достаётся готовым.
• WORKDIR /app объявляет текущий каталог для последующих COPY, RUN, CMD.
• COPY <откуда> <куда> копирует файлы из каталога проекта, называемого контекстом сборки, внутрь образа.
• RUN выполняет команду во время сборки и сохраняет результат в образ. Здесь же устанавливаются системные пакеты наподобие RUN apt-get update && apt-get install -y gfortran.
• CMD указывает, что запускать при старте контейнера. Выполняется не при сборке, а при docker run, и легко переопределяется командой docker run мой-образ bash.

Слои и кеширование: отдельное копирование requirements.txt

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

Код (simulate.py) правится по двадцать раз в день, а requirements.txt раз в месяц. Если бы COPY . . располагалась до установки зависимостей, любая правка, сделанная в коде, инвалидировала бы слой копирования, и Docker заново выполнял бы pip install со скачиванием numpy и scipy, что означает пять минут ожидания после каждой изменённой строки. В приведённом порядке слой с зависимостями зависит только от requirements.txt: при правке кода пересобирается лишь дешёвый COPY . ., и сборка занимает секунды. Правило: редко меняющееся выше, часто меняющееся ниже.

Файл .dockerignore устроен по образцу .gitignore: в нём перечисляются .git, __pycache__, данные и прочее, что не должно попадать в образ.

Сборка и запуск

# Собрать образ из Dockerfile в текущем каталоге (точка — контекст сборки).
# -t задаёт имя и тег.
docker build -t beam-simulation:0.1 .

# Тег можно навесить и потом (это просто ярлык на тот же образ)
docker tag beam-simulation:0.1 beam-simulation:latest

# Запуск: результаты пишем в примонтированный каталог,
# иначе они умрут вместе с контейнером
docker run --rm -v "$(pwd)/results":/app/results beam-simulation:0.1

# Переопределить CMD: запустить другой скрипт из того же образа
docker run --rm beam-simulation:0.1 python -m beamlib.diagnostics

Весь расчёт сводится к одной команде, воспроизводимой на любой машине с Docker.

Реестры: Docker Hub и ghcr.io

Передать образ коллеге можно файлом (docker save и docker load), однако стандартным путём является реестр (registry), устроенный как git-хостинг для образов. По умолчанию используется публичный Docker Hub, откуда был скачан python:3.12-slim. Второй популярный вариант, GitHub Container Registry (ghcr.io), удобен тем, что образы располагаются рядом с кодом проекта на GitHub и собираются автоматически через GitHub Actions.

Имя образа, отправляемого в реестр, должно включать аккаунт владельца, после чего выполняется docker push.

# тегируем образ под свой аккаунт на Docker Hub
docker tag beam-simulation:0.1 fuodorov/beam-simulation:0.1

docker login                            # авторизация (однократно)
docker push fuodorov/beam-simulation:0.1

# коллега на любой машине делает:
docker pull fuodorov/beam-simulation:0.1

# для ghcr.io всё то же, только префикс реестра в имени:
docker tag beam-simulation:0.1 ghcr.io/fuodorov/beam-simulation:0.1
docker push ghcr.io/fuodorov/beam-simulation:0.1

Docker Compose: несколько контейнеров

Система редко состоит из одного контейнера: типичный сценарий — приложение, записывающее результаты в базу данных PostgreSQL. Запускать оба контейнера вручную, настраивать сеть между ними, помнить порядок запуска и десяток флагов утомительно. Docker Compose описывает всю связку декларативно, в одном файле compose.yaml:

services:
  app:
    build: .                    # собрать образ из Dockerfile в текущем каталоге
    volumes:
      - ./results:/app/results  # результаты — на хост
    environment:
      DB_HOST: db               # имя сервиса работает как сетевое имя хоста
      DB_USER: physicist
      DB_PASSWORD: secret
    depends_on:
      db:
        condition: service_healthy  # приложение стартует, когда база начала принимать соединения

  db:
    image: postgres:16          # готовый образ с Docker Hub
    environment:
      POSTGRES_USER: physicist
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: measurements
    healthcheck:                # проверка готовности, а не только запуска процесса
      test: ["CMD-SHELL", "pg_isready -h 127.0.0.1 -U physicist -d measurements"]
      interval: 2s
      retries: 15
    volumes:
      - pgdata:/var/lib/postgresql/data   # именованный том: данные переживут контейнер

volumes:
  pgdata:

Compose автоматически создаёт общую сеть, в которой контейнеры видят друг друга по именам сервисов, объявленным в файле, и приложение подключается к базе по адресу db:5432, без IP. Сам по себе depends_on ждёт только запуска контейнера базы, а не её готовности: при первом запуске PostgreSQL сначала создаёт кластер и базу, и приложение, подключившееся в это время, получает отказ в соединении. Условие service_healthy откладывает запуск приложения до первой успешной проверки healthcheck. Команда pg_isready с ключом -h 127.0.0.1 проверяет сервер по TCP, как и приложение: на время инициализации образ запускает временный сервер, доступный только через локальный сокет. Основные команды:

docker compose build      # только собрать образы, не запуская
docker compose up -d      # собрать и запустить всё; -d — в фоне
docker compose logs -f    # смотреть логи всех сервисов
docker compose ps         # какие сервисы подняты и какие порты опубликованы
docker compose down       # остановить и удалить контейнеры (тома останутся)

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

Видимость портов снаружи и внутри

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

services:
  nginx:
    image: nginx:1.27
    ports:
      - "80:80"     # опубликовать наружу: порт 80 хоста -> порт 80 контейнера
  backend:
    build: ./backend
    expose:
      - "8000"      # видно соседям по сети Compose и самому хосту по внутреннему адресу контейнера, но не из внешней сети

ports публикует порт на хост, и по нему в контейнер может обратиться любой, у кого есть доступ к машине. expose не публикует ничего, а лишь помечает порт, на котором сервис слушает, для соседей по той же сети. Обычная схема рабочего стенда: снаружи опубликован единственный порт, а за ним стоит nginx, раздающий статику фронтенда и перенаправляющий запросы к API на бэкенд по имени сервиса. Такой nginx называется обратным прокси, и в его конфигурации достаточно одной секции:

server {
    listen 80;
    location / {
        root /usr/share/nginx/html;     # собранный фронтенд
    }
    location /api/ {
        proxy_pass http://backend:8000/;   # backend — имя сервиса из compose.yaml
    }
}

Порт, не опубликованный наружу, недоступен из сети: база данных и бэкенд остаются недосягаемыми для других машин, даже если в них обнаружится уязвимость. Проверкой служит команда docker compose ps: публикация должна присутствовать ровно у одного сервиса, а curl localhost:8000 на хосте отвечать не должен.

Контейнеры в науке

Контейнер является ответом рецензенту, требующему воспроизвести результаты. Всё чаще к статье прикладывают не только код, но и собранный образ или хотя бы Dockerfile, помещённый в репозиторий. Одной команды docker run с опубликованным образом достаточно, чтобы читатель получил те же графики из тех же данных, с точностью до версий всех задействованных библиотек. Dockerfile воспроизводит окружение, только если базовый образ указан дайджестом (FROM python:3.12-slim@sha256:…), а версии пакетов зафиксированы: тег python:3.12-slim со временем начинает указывать на новую сборку. На суперкомпьютерах Docker обычно не устанавливают: его служба работает с правами root, а доступ к ней равносилен правам root на узле. Там используется Apptainer — под этим именем проект Singularity с 2021 года входит в Linux Foundation, а компания Sylabs развивает его ответвление SingularityCE. Apptainer спроектирован для HPC: он запускает контейнеры без прав root, совместим с MPI и GPU и собирает образы из образов Docker. Образ, собранный на рабочем компьютере, запускается и на кластере, если совпадает архитектура процессора (образ для x86-64 не запустится на узлах ARM), библиотека MPI в образе совместима с MPI и сетью кластера, а драйвер видеокарты подключается с хоста (ключ --nv); подробно Apptainer и запуск расчётов на кластере рассмотрены в главе «Кластеры и воспроизводимое окружение для расчётов».

Полезные ссылки

• Docker
• Docker CLI
• Виртуализация и контейнеризация
• Проникновение в Docker с примерами
• Оптимизация образов Docker
• Документация на docker network
• Docker: гибкая сеть без NAT на все случаи жизни
• Docker Compose
• Docker Compose CLI

Задание. Упаковать бэкенд и фронтенд в образы и связать их через docker compose: «Деплой стартапа „Котики в мир“».

Устройство интерпретатора Python

… in December 1989, I was looking for a “hobby” programming project that would keep me occupied during the week around Christmas. My office … would be closed, but I had a home computer, and not much else on my hands.

Гвидо ван Россум, предисловие к «Programming Python» (1-е изд.)

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

В настоящей части рассматривается внутреннее устройство языка. Настоящая глава описывает путь программы от исходного текста до исполнения: реализации языка, байт-код, модули и интерактивную оболочку. Затем рассматриваются объекты и память — то, что скрывается за именем переменной, — коллекции, собираемые из этих объектов, и стоимость операций над ними. Далее следуют функции и построенные на них итераторы с генераторами, обеспечивающие механизм отложенных вычислений. Завершают часть декораторы и классы, два способа наращивать поведение, не переписывая уже работающий код.

Когда обработка данных, полученных в эксперименте, занимает часы вместо минут, причина почти всегда состоит не в «медленном Python», а в неудачно выбранной структуре данных или лишнем копировании.

Слайды к главе. Материал главы изложен также в первой части лекции «Python. Начало», продолжение лекции относится к трём следующим главам; слайды лекции доступны на сайте книги и в PDF.

Язык и его реализации

Python — язык, описанный спецификацией (The Python Language Reference), и у него несколько реализаций. Эталонной и самой распространённой является CPython, написанный на C: именно он устанавливается с python.org и из пакетов дистрибутивов Linux. PyPy компилирует часто выполняемые участки программы в машинный код во время работы (JIT), поэтому циклы на чистом Python выполняются в нём в несколько раз быстрее. MicroPython работает на микроконтроллерах с сотнями килобайт памяти, GraalPy — на виртуальной машине GraalVM.

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

Путь исходного текста

CPython не исполняет исходный текст напрямую. Лексический анализатор разбивает текст на токены: имена, числа, строки, операторы, отступы. Синтаксический анализатор строит из токенов абстрактное синтаксическое дерево (AST). Компилятор обходит дерево и порождает байт-код — последовательность инструкций виртуальной стековой машины, упакованную вместе с таблицами констант и имён в объект кода. Этот объект исполняет цикл вычисления интерпретатора, по одной инструкции за шаг. Каждый этап доступен из самого Python: модули tokenize и ast, встроенная функция compile и модуль dis.

Байт-код функции печатает модуль dis; здесь и далее приведён вывод CPython 3.12.

import dis

def area(r):
    return 3.14159 * r ** 2

dis.dis(area)

  3           0 RESUME                   0

  4           2 LOAD_CONST               1 (3.14159)
              4 LOAD_FAST                0 (r)
              6 LOAD_CONST               2 (2)
              8 BINARY_OP                8 (**)
             12 BINARY_OP                5 (*)
             16 RETURN_VALUE

Первый столбец — номер строки исходного текста, второй — смещение инструкции в байтах. Инструкции берут операнды с вершины стека значений и кладут туда результат: LOAD_CONST загружает константу, LOAD_FAST — локальную переменную, BINARY_OP снимает два значения и кладёт результат операции, RETURN_VALUE возвращает вершину стека вызывающему коду. RESUME в начале функции служит точкой, в которой интерпретатор проверяет запросы трассировки. Выражения из одних констант компилятор вычисляет заранее: в байт-коде присваивания x = 2 * 3.14159 остаётся одна константа 6.28318.

С версии 3.11 интерпретатор адаптивный (PEP 659): во время работы он заменяет общие инструкции специализированными. Уже после двух вызовов area(1.0) функция dis.dis(area, adaptive=True) показывает вместо второго BINARY_OP инструкцию BINARY_OP_MULTIPLY_FLOAT, умножающую именно вещественные числа. Байт-код не входит в спецификацию языка: набор инструкций меняется от версии к версии, поэтому вывод dis в материалах о других версиях выглядит иначе.

Модули и файлы .pyc

Каждый файл .py является модулем. Инструкция import circle находит файл circle.py, создаёт объект модуля, заносит его в словарь sys.modules и выполняет файл сверху вниз; имена, определённые в файле, становятся атрибутами модуля: circle.area. Повторный import находит модуль в sys.modules и файл заново не выполняет. Байт-код импортированного модуля сохраняется в каталоге __pycache__ в файле с тегом версии интерпретатора (circle.cpython-312.pyc) и используется повторно, пока исходный файл не изменился; запускаемый сценарий компилируется при каждом запуске.

У импортированного модуля атрибут __name__ равен его имени, а у файла, запущенного как сценарий, — строке "__main__". На этом основана идиома, позволяющая одному файлу служить и сценарием, и библиотекой функций: код под условием выполняется при запуске файла и не выполняется при его импорте.

def main():
    ...

if __name__ == "__main__":
    main()

Модули ищутся по списку каталогов sys.path, и после встроенных в интерпретатор модулей первым просматривается каталог запускаемого сценария. Поэтому файл random.py или numpy.py, созданный рядом со сценарием, подменяет одноимённый модуль стандартной библиотеки или установленного пакета, и импорт завершается непонятной ошибкой вида AttributeError: module 'random' has no attribute 'randint'. Имя собственного файла выбирается так, чтобы не совпадать с именами модулей.

Интерактивная оболочка

Интерактивная оболочка (REPL, read–eval–print loop) читает строку, выполняет её и печатает значение выражения; приглашение ... означает, что оболочка ждёт продолжения блока. Для исследования объектов служат функции help, dir, type и id, а значение последнего выражения сохраняется в переменной _. Команда python3 -i run.py выполняет сценарий и оставляет оболочку открытой со всеми его переменными, что удобно для разбора ошибки. В Python 3.13 оболочка получила многострочное редактирование и цветные сообщения об ошибках, а IPython и блокноты Jupyter дополняют её сохранением кода, результатов и графиков.

Объекты и память

В настоящей главе рассматривается то, что скрывается за именем переменной: чем изменяемые объекты отличаются от неизменяемых, почему это различие проявляется в неожиданных местах, а также как устроены условные конструкции и циклы.

Слайды к главе. Материал главы изложен также во второй, третьей и четвёртой частях лекции «Python. Начало» (объекты в памяти, изменяемость, сборка мусора) с демонстрациями в интерактивной оболочке; слайды лекции доступны на сайте книги и в PDF.

Объекты в памяти

В Python объектом является всё: и число, и строка, и функция, и сам класс. Любой объект обладает тремя свойствами. Тип определяет набор действий, разрешённых с объектом (int, str, list). Значение представляет собой данные, хранящиеся внутри объекта (42, "hello"). Идентификатор является числом, которое не меняется на всё время жизни объекта и уникально среди объектов, существующих одновременно: после уничтожения объекта его идентификатор может достаться новому. В CPython это адрес объекта в памяти, получаемый функцией id().

s = "hello"
print(id(s))  # Выведет что-то вроде 4390213040

Ссылки, а не копии

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

a = [1, 2, 3]
b = a
b.append(4)
print(a)  # [1, 2, 3, 4] — изменился и a!

Сравнение is и ==

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

x = [1, 2]
y = [1, 2]
print(x == y)  # True
print(x is y)  # False

Кеширование целых чисел

При запуске интерпретатор заранее создаёт объекты для небольших целых чисел (в CPython 3.10–3.14 это диапазон от −5 до 256, в 3.15 кеш расширен), и все переменные с такими значениями ссылаются на один и тот же заранее созданный объект.

a = 256
b = 256
print(a is b)  # True — это один и тот же закешированный объект

Для 257 результат зависит от того, каким образом запускается код.

c = 257
d = 257
print(c is d)

При запуске этого фрагмента в виде файла будет получено True, тогда как при вводе тех же трёх строк в интерактивной оболочке результатом окажется False.

Причина заключается не в кеше чисел, а в работе компилятора. Python компилирует файл целиком и объединяет одинаковые константы всех его функций, поэтому c и d получают ссылку на одну и ту же константу. В интерактивной оболочке каждая строка компилируется отдельно, общей таблицы нет, и создаются два разных объекта.

Тождественность объектов относится к деталям реализации, и опираться на неё нельзя. Она зависит от версии интерпретатора, от способа запуска (файл целиком или отдельные строки интерактивной оболочки) и от того, получено значение при компиляции или вычислено во время работы программы.

💡 Золотое правило: для сравнения значений необходимо использовать ==, а is применять только для проверки на None, True и False.

Изменяемые и неизменяемые объекты

Это основное деление объектов Python.

Неизменяемые (immutable)

К неизменяемым относятся int, float, str, tuple, bytes и bool. Однажды созданный объект хранит своё значение навсегда. Любая «модификация» создаёт новый объект, на который переставляется старое имя, в чём проще всего убедиться по идентификатору, меняющемуся после каждого +=.

s = "hello"
print(id(s))
s += "!"
print(id(s))  # ID изменился — это новый объект!

Изменяемые (mutable)

list, dict и set, напротив, изменяются на месте. Список после append остаётся тем же самым объектом, в котором лишь стало на один элемент больше, и все имена, ссылавшиеся на него, увидят добавленный элемент.

lst = [1, 2]
print(id(lst))
lst.append(3)
print(id(lst))  # ID остался прежним

Кортежи с изменяемыми элементами

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

t = ([1, 2], [3, 4])
t[0].append(3)
print(t)  # ([1, 2, 3], [3, 4]) — это допустимо!

Такой кортеж нельзя поместить в множество или использовать как ключ словаря, поскольку хеш кортежа складывается из хешей его элементов, а у списка хеша нет. Попытка завершится исключением TypeError: unhashable type: 'list' при вставке.

Строки и байты

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

Строки (str)

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

Байты (bytes)

bytes хранит сырые данные, то есть последовательность чисел от 0 до 255: то, что находится в файле, приходит по сети или считывается с прибора. Понятие «символ» здесь отсутствует, есть только числа. Тип также является неизменяемым; его изменяемый вариант называется bytearray.

Автоматического перехода между ними нет, поскольку требуется кодировка, указывающая, каким набором байтов записан каждый символ. encode преобразует текст в байты, decode — байты в текст.

text = "привет"
encoded = text.encode('utf-8')  # str -> bytes
decoded = encoded.decode('utf-8')  # bytes -> str

Кириллица в UTF-8 занимает по два байта на символ, поэтому len(text) даст 6, а len(encoded) вернёт 12. Почти все UnicodeDecodeError возникают именно отсюда: байты читаются не в той кодировке, в которой были сохранены.

Условные конструкции

Базовый синтаксис

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

temperature = 15
if temperature > 20:
    print("Наденьте футболку")
else:
    print("Лучше взять куртку")

Элегантные проверки

В условии не обязательно записывать сравнение, поскольку любой объект сам по себе истинен или ложен: пустая строка, пустой список, ноль и None ложны, всё остальное истинно. Поэтому if name: читается как «если имя есть» и заменяет if name != "":

name = input("Введите имя: ")
if name:  # False, если строка пустая
    print(f"Привет, {name}!")
else:
    print("Привет, незнакомец!")

Современный match (Python 3.10+)

Когда одну переменную необходимо сравнить с десятком значений, цепочка из elif становится нечитаемой, и для этого случая предусмотрен match, аналог switch из других языков. Ветви перебираются сверху вниз, вертикальная черта объединяет несколько вариантов в один случай, а case _ перехватывает всё, что не было перехвачено раньше.

http_status = 404
match http_status:
    case 200 | 201:
        print("Успех")
    case 401 | 403 | 404:
        print("Ошибка клиента")
    case 500 | 503:
        print("Ошибка сервера")
    case _:
        print("Неизвестный статус")

💡 Совет: match следует применять при сравнении одной переменной с несколькими значениями. Для сложных условий предпочтительнее if/elif/else.

Циклы

while

while повторяет тело, пока условие истинно, и требуется там, где число итераций заранее неизвестно, например пока значение не выйдет за заданную границу.

i = 1
while i < 1000:
    print(i)
    i *= 2

for и range

for в Python перебирает не индексы, а элементы; если необходим счётчик, его предоставляет range. С одним аргументом он отсчитывает от нуля, с тремя задаёт начало, границу и шаг. Правая граница в диапазон не входит.

for i in range(5):      # 0, 1, 2, 3, 4
    print(i)

for i in range(1, 10, 2):  # 1, 3, 5, 7, 9
    print(i)

enumerate для получения индекса

Когда вместе с элементом требуется и его номер, заводить отдельный счётчик не нужно: enumerate выдаёт пары «индекс, элемент», распаковываемые в заголовке цикла.

for idx, char in enumerate("abc"):
    print(f"Индекс: {idx}, Символ: {char}")

Ветка else в циклах

У циклов в Python есть ветка else, почти не встречающаяся в других языках. Она выполняется, если цикл завершился естественно, то есть перебрал всё до конца и ни разу не встретил break. Это готовый каркас для поиска: в теле цикла выполняется поиск с выходом по break, а в else записывается ветка «не найдено».

for i in range(5):
    if i == 10:
        break
else:
    print("Цикл завершился без break")

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

Каждое += для строки создаёт новый объект и копирует в него всё накопленное ранее. На сотой итерации копируется сто символов, на стотысячной — сто тысяч, и в сумме получается квадратичное время вместо линейного.

result = ""
for _ in range(100000):
    result += "a"  # Создаёт новый объект на каждой итерации!

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

Правильнее накапливать части в списке и объединить их один раз. Список изменяем, append ничего не копирует, а join заранее вычисляет итоговую длину, выделяет память один раз и переносит туда все части.

parts = []
for _ in range(100000):
    parts.append("a")
result = "".join(parts)  # Быстрое объединение

💡 Совет: для частых операций конкатенации рекомендуется использовать list + join() для строк или bytearray для байтов.

Сборка мусора

Память под объекты в Python освобождается автоматически, и обеспечивается это двумя механизмами.

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

Слабым местом подсчёта ссылок являются циклические ссылки. Если объекты ссылаются друг на друга, их счётчики никогда не обнулятся, даже когда до них уже нельзя добраться из программы.

a = []
b = [a]
a.append(b)  # Теперь a и b ссылаются друг на друга
del a, b     # Объекты недостижимы, но ссылки остались

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

Неочевидные особенности Python

1. Изменяемые аргументы по умолчанию

Наиболее известная ловушка языка. Значение по умолчанию, записанное в заголовке, вычисляется один раз, когда интерпретатор доходит до строки def, после чего список сохраняется между вызовами и накапливает всё помещённое в него.

def append_to(element, target=[]):  # так делать нельзя!
    target.append(element)
    return target

print(append_to(1))  # [1]
print(append_to(2))  # [1, 2] — тот же список!

Решение: по умолчанию указывается None, а пустой список создаётся внутри функции, заново при каждом вызове.

def append_to(element, target=None):
    if target is None:
        target = []
    target.append(element)
    return target

2. Ленивые логические операторы

and и or вычисляют правую часть только тогда, когда без неё нельзя обойтись. Если левый операнд and ложен, результат уже известен, и правая часть не вычисляется. Благодаря этому выражение if xs and xs[0] > 0 не приведёт к ошибке на пустом списке.

def expensive_call():
    print("Вызов выполнен!")
    return True

# expensive_call() не будет вызвана, т.к. первое условие False
if False and expensive_call():
    pass

3. Атрибуты функций

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

def my_func():
    pass

my_func.custom_attr = 42
print(my_func.custom_attr)  # 42

Заключение

Переменная представляет собой имя, привязанное к объекту, а не контейнер со значением. Отсюда следуют и общий список после двух присваиваний, и накопительный аргумент по умолчанию, и квадратичное время сборки строки через +=.

Таким образом, можно сформулировать четыре правила:

• is применяется только для None, True и False; во всех остальных случаях используется ==.
• Строки собираются через join, а не через += в цикле.
• Значение по умолчанию не должно быть изменяемым объектом, вместо него указывается None.
• Прежде чем передать объект в стороннюю функцию, необходимо определить, изменяем он или нет.

Полезные материалы:

• Python Documentation
• Ned Batchelder — Facts and Myths about Python Names and Values
• Real Python — Python Memory Management

Коллекции

Коллекции составляют основу хранения и обработки данных в Python. В настоящей главе рассматриваются конкретные типы, встроенные в язык, и их устройство, тогда как сами структуры данных, дек и хеш-таблица в их общем виде, разбираются в части «Алгоритмы и структуры данных»; стоимость конкретных операций над списком, множеством и словарём оценивается в следующей главе. Выбор между ними определяет, будет программа выполняться секунды или часы.

Слайды к главе. Материал главы изложен также в пятой части лекции «Python. Начало» с демонстрациями в интерактивной оболочке; слайды лекции доступны на сайте книги и в PDF.

Понятие коллекции

Коллекцией в Python стандартная библиотека называет объект с тремя свойствами. Он является контейнером (Container), то есть отвечает на оператор in; он итерируемый (Iterable), и его элементы можно перебрать в цикле; он ограниченной длины (Sized), а значит знает, сколько в нём элементов, и отвечает на len().

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

from collections.abc import Collection

# Проверим, является ли список коллекцией
print(isinstance([1, 2, 3], Collection))  # True

Любопытные исключения

• Числовой интервал служит контейнером: про любое число можно сказать, лежит оно внутри или нет. Однако перебрать все его точки нельзя, и длины, измеряемой в элементах, у него нет.
• Генератор итерируем, но заранее не знает, сколько элементов выдаст, и не способен отвечать на in, не израсходовав себя.

Синтаксис @dataclass и магические методы, за которыми стоят операторы наподобие in, разбираются в главе «Классы»; здесь описывается собственный тип, отвечающий на in.

# Пример: Интервал как контейнер
from dataclasses import dataclass

@dataclass
class Interval:
    a: float
    b: float

    def __contains__(self, x):
        return self.a < x < self.b

interval = Interval(0, 1)
print(0.5 in interval)  # True — оператор in работает

# а вот длины у интервала нет и быть не может:
# len(interval) -> TypeError: object of type 'Interval' has no len()

Иерархия коллекций

Стандартная библиотека Python определяет абстрактные базовые классы (ABC), по которым коллекции и классифицируются:

   Container      Iterable       Sized          три независимых свойства
       |             |             |
       +-------------+-------------+
                     |
                 Collection        объект, обладающий всеми тремя
                     |
        +------------+------------+
        |            |            |
    Sequence        Set        Mapping

Container, Iterable и Sized представляют собой три независимых свойства, и объект может обладать любым их сочетанием. Генератор итерируем, но не знает своей длины; рассмотренный выше Interval, не позволяющий перебирать точки, остаётся контейнером. Collection объединяет все три свойства, потому и наследуется от всех трёх.

Ниже располагаются три семейства:

• Sequence (последовательности), где элементы упорядочены и доступны по индексу. Сюда относятся списки, кортежи и строки.
• Set (множества), где элементы уникальны, а порядка, связывающего их, нет. Это set и frozenset.
• Mapping (отображения), хранящие пары «ключ, значение». Это словари.

Списки (list): универсальные и изменяемые

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

Неочевидные особенности инициализации

Умножение списка на число повторяет только ссылки. Если внутри находится изменяемый объект, все скопированные ссылки укажут на него же, и изменение через один индекс отразится во всех остальных. Классическая ошибка — матрица, у которой все строки одинаковые:

# Кажется, что это создаст матрицу 2x1
chunks = [[0]] * 2
chunks[0][0] = 42
print(chunks)  # [[42], [42]] Оба элемента ссылаются на один и тот же список!

# Правильный способ: включение создаёт новый список на каждой итерации
correct_chunks = [[0] for _ in range(2)]
correct_chunks[0][0] = 42
print(correct_chunks)  # [[42], [0]] — а вот теперь как надо

Тело включения выполняется на каждой итерации заново, и [0] создаёт новый список каждый раз.

Эффективные операции

Внутренне список устроен как динамический массив, и стоимость операций следует из этого устройства. append(item) и pop(), работающие с последним элементом, имеют амортизированную сложность O(1). insert(0, item) и pop(0) сдвигают все элементы и имеют сложность O(n). extend(iterable) выгоднее серии append(), поскольку один раз оценивает требуемый размер вместо наращивания списка по одному элементу.

Совет: При необходимости частых операций с обоих концов целесообразно использовать collections.deque (устройство дека и сравнительные измерения со списком приведены в главе «Основные структуры данных»).

Кортежи (tuple): неизменяемые и хешируемые

Неизменяемость даёт кортежу свойство, отсутствующее у списка: кортеж хешируем, а значит, подходит для ключей словаря и элементов множества. Пара координат, связка «прибор, канал», дата, записанная тремя числами, помещаются в кортеж и становятся ключом.

Распаковка кортежей

Распаковка разбирает кортеж на переменные одним присваиванием. Звёздочка слева от знака равенства собирает остаток в список, подчёркивание по соглашению помечает ненужное значение, а звёздочка в вызове функции работает в обратную сторону и раскладывает кортеж по аргументам.

# Распаковка с упаковкой «лишних» элементов в переменную
first, second, *rest = range(10)
print(first, second, rest)  # 0 1 [2, 3, 4, 5, 6, 7, 8, 9]

# Игнорирование ненужных значений
x, _, z = (1, 2, 3)

# Распаковка в аргументы функции
def greet(name, greeting):
    return f"{greeting}, {name}!"

person = ("Alice", "Hello")
print(greet(*person))  # "Hello, Alice!"

Именованные кортежи (namedtuple)

Через месяц смысл, вложенный в point[1], оказывается забытым. collections.namedtuple является фабрикой классов, создающей подтип кортежа с именованными полями. Полученный объект остаётся кортежем со всеми его свойствами, но к элементам можно обращаться по имени.

from collections import namedtuple

Point = namedtuple('Point', ['x', 'y'])
p = Point(10, y=20)
print(p.x, p.y)  # 10 20
print(p._asdict()) # {'x': 10, 'y': 20}

Метод _asdict() преобразует такой кортеж в словарь, что удобно для вывода и сериализации. Имена полей задаются пользователем, поэтому служебные методы помечаются подчёркиванием, чтобы они не столкнулись с полем, названным asdict.

Множества (set): уникальность и скорость

Множества реализованы как хеш-таблицы, рассматриваемые в главе «Хеш-функции», поэтому проверка вхождения (in) имеет среднюю сложность O(1), и время не зависит от размера множества.

Неочевидные применения множеств

Множество применяется не только ради уникальности, но и ради быстрой проверки принадлежности.

1. Удаление дубликатов из списка.

   unique_list = list(set(duplicated_list))
   

2. Подсчёт элементов, встречающихся сразу в двух коллекциях.

   common = set(list1) & set(list2)
   

3. Фильтрация «мусора» при разборе данных.

   valid_tags = {'python', 'tutorial', 'advanced'}
   tags = ['python', 'beginner', 'advanced']
   filtered_tags = [tag for tag in tags if tag in valid_tags]
   # ['python', 'advanced']
   

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

frozenset: неизменяемое множество

Обычные множества изменяемы и потому нехешируемы: вложить их в другое множество или сделать ключом словаря не удастся. Правило то же, что с кортежами и списками: хешируемо только то, что не изменяется. Неизменяемый вариант множества называется frozenset.

# Множество множеств? Нет.
# {set([1,2]), set([3,4])}  # TypeError: unhashable type: 'set'

# А так — можно.
fs1 = frozenset([1, 2])
fs2 = frozenset([3, 4])
meta_set = {fs1, fs2}  # Valid

Словари (dict): сердце Python

Словарь является наиболее нагруженной структурой в языке. На нём построены пространства имён модулей, атрибуты объектов и передача именованных аргументов. Начиная с Python 3.7 словарь гарантированно сохраняет порядок добавления элементов; ранее это было деталью реализации CPython 3.6, не оговорённой в языке.

Малоизвестные возможности словарей

1. Метод setdefault() возвращает значение по ключу, а при отсутствующем ключе сначала помещает в словарь указанное значение, за один поиск по хеш-таблице вместо двух.

   data = {}
   # Классический, но неэффективный способ
   if 'key' not in data:
       data['key'] = []
   data['key'].append(1)
   
   # Эффективный способ с setdefault
   data.setdefault('key', []).append(1)
   

2. Метод popitem() удаляет и возвращает пару (ключ, значение) в порядке LIFO (последним пришёл, первым ушёл). Полезен для обработки данных в обратном порядке.

3. Словарные включения (Dict Comprehensions).

   squares = {x: x*x for x in range(5)}
   # {0: 0, 1: 1, 2: 4, 3: 9, 4: 16}
   

Коллекции из модуля collections

Для частых сценариев в стандартной библиотеке предусмотрены готовые надстройки над четырьмя базовыми типами. Counter, defaultdict и OrderedDict являются подклассами словаря, а deque поддерживает интерфейс последовательности, поэтому большая часть кода работает с ними без изменений. Исключения всё же есть: у дека нет срезов, а defaultdict создаёт ключ уже при чтении d[k].

• defaultdict, словарь с фабричной функцией, отвечающей за недостающие ключи.

  from collections import defaultdict
  graph = defaultdict(list)
  graph['a'].append('b')  # Не нужно проверять, есть ли ключ 'a'
  

• Counter, подкласс словаря, подсчитывающий хешируемые объекты.

  from collections import Counter
  words = ['apple', 'banana', 'apple', 'orange']
  word_count = Counter(words)
  print(word_count.most_common(1))  # [('apple', 2)]
  

• deque, двусторонняя очередь, пополняемая с обоих концов. Подходит для очередей (FIFO) и стеков (LIFO).

  from collections import deque
  queue = deque([1, 2, 3])
  queue.append(4)    # O(1)
  queue.popleft()    # O(1) — в отличие от списка!
  

• OrderedDict, словарь, сохраняющий порядок. В Python 3.7+ обычный dict также упорядочен, но у OrderedDict есть дополнительные методы (move_to_end, popitem(last=True/False)).

Заключение

Выбор коллекции определяет эффективность и корректность программы. Это решение принимается в начале, когда переписывание ещё обходится дёшево.

• Список применяется, когда важен порядок и данные изменяются.
• Кортеж подходит, когда данные фиксированы или требуется хешируемый объект.
• Множество выбирается ради уникальности и быстрой проверки вхождения.
• Словарь уместен, когда у данных есть естественный ключ.
• Специализированные коллекции из модуля collections необходимы тогда, когда стандартная четвёрка обрастает обвязкой из проверок и заглушек.

В следующей главе эти рекомендации переводятся в числа: во что обходится каждая операция и как измерить это самостоятельно.

Задание. Собрать словарь цепочек и сгенерировать по нему текст: «Генерация текста на основе данных».

Сложность операций с коллекциями

Здесь рассматривается, во что обходятся конкретные операции над списком, множеством и словарём и почему выбор структуры определяет больше, чем оптимизация кода. Сама O-нотация со всей строгостью разбирается далее, в главе «Введение в алгоритмы».

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

Слайды к главе. Материал главы изложен также в шестой части лекции «Python. Начало» с замерами в терминале; слайды лекции доступны на сайте книги и в PDF.

В нотации O-большое описывается, как время выполнения алгоритма растёт вслед за размером входных данных.

Значение сложности

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

from timeit import timeit
import random

# Сравним поиск в списке и множестве
large_list = list(range(1000000))
large_set = set(large_list)

# Ищем случайный элемент
target = random.randrange(1000000)

# Время поиска в списке (O(n))
list_time = timeit(lambda: target in large_list, number=1000)
# Время поиска в множестве (O(1))
set_time = timeit(lambda: target in large_set, number=1000)

print(f"Поиск в списке: {list_time:.4f} сек")
print(f"Поиск в множестве: {set_time:.4f} сек")

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

Сложность операций со списками

Константное время O(1)

my_list = [1, 2, 3, 4, 5]

# Эти операции выполняются за постоянное время
my_list.append(6)      # Добавление в конец
last = my_list.pop()   # Удаление с конца
element = my_list[2]   # Доступ по индексу
length = len(my_list)  # Получение длины

Почему O(1): список в Python устроен как динамический массив указателей. Он выделяет память с запасом, поэтому append записывает указатель в свободную ячейку и увеличивает счётчик длины, не перемещая остальные элементы.

Изредка запас исчерпывается, и списку приходится выделить больший блок памяти и скопировать туда все элементы, что стоит \( O(n) \). Однако поскольку размер увеличивается кратно, перевыделения происходят всё реже, и в среднем на одну операцию по-прежнему приходится константа. Такую усреднённую сложность называют амортизированной \( O(1) \).

Линейное время O(n)

my_list = [1, 2, 3, 4, 5]

# Эти операции требуют обхода или сдвига элементов
my_list.insert(0, 0)   # Вставка в начало → сдвиг всех элементов
my_list.remove(3)      # Поиск и удаление элемента
element in my_list     # Поиск элемента
my_list.index(4)       # Поиск индекса элемента

Почему O(n): при вставке в начало все элементы, следующие далее, приходится сдвигать на одну позицию. А in, remove и index проходят по списку с начала, сравнивая элементы: заранее известного места под значение у массива нет.

Медленный и быстрый код

Обе функции ниже удаляют дубликаты с сохранением порядка. Отличие в одной строке: первая проверяет item not in result по списку, вторая обращается к множеству seen. За строкой внутри цикла скрывается ещё один проход по всем элементам, превращающий линейный алгоритм в квадратичный.

# НЕЭФФЕКТИВНО: O(n²)
def remove_duplicates_slow(data):
    result = []
    for item in data:
        if item not in result:  # O(n) для каждого элемента!
            result.append(item)
    return result

# ЭФФЕКТИВНО: O(n)
def remove_duplicates_fast(data):
    seen = set()
    result = []
    for item in data:
        if item not in seen:    # O(1) проверка!
            seen.add(item)
            result.append(item)
    return result

# Тестируем на семи тысячах случайных чисел
import random
data = [random.randrange(7000) for _ in range(7000)]

slow_time = timeit(lambda: remove_duplicates_slow(data), number=1)
fast_time = timeit(lambda: remove_duplicates_fast(data), number=1)

print(f"Медленная версия: {slow_time:.4f} сек")   # 0.0520
print(f"Быстрая версия:   {fast_time:.4f} сек")   # 0.0002

Разница составляет двести пятьдесят раз, и растёт она вместе с объёмом. На семидесяти тысячах элементов медленная версия выполняется за 4.6 секунды против 2 миллисекунд у быстрой, то есть отстаёт почти в две тысячи раз. Время первой выросло в девяносто раз при десятикратном росте данных: это и есть квадратичность.

Следует отметить тонкость самого измерения. Если вместо случайных чисел подставить набор [1, 2, 2, 3, 4, 4, 5] * 1000, содержащий те же семь тысяч элементов, разница сократится до полутора раз вместо двухсот пятидесяти. Причина в том, что различных значений там всего пять. Список result, растущий только на новых значениях, не превысит пяти элементов, проверка item not in result пройдёт по пяти элементам вместо тысяч, и квадратичность не проявится.

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

Сложность операций с множествами

В основе множества лежит хеш-таблица, рассмотренная в главе про хеш-функции, поэтому большинство операций имеют сложность O(1).

my_set = {1, 2, 3, 4, 5}

# O(1) операции
my_set.add(6)           # Добавление
my_set.remove(3)        # Удаление
4 in my_set             # Проверка вхождения
len(my_set)             # Длина

# операции над двумя множествами — сложность у каждой своя
s1 = {1, 2, 3}
s2 = {3, 4, 5}
union = s1 | s2         # объединение:  O(len(s1) + len(s2))
intersection = s1 & s2  # пересечение:  O(min(len(s1), len(s2)))
difference = s1 - s2    # разность:     O(len(s1))

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

Интересный факт: при массовых коллизиях хешей операции с множеством вырождаются в O(n). На практике это почти не встречается, за исключением случаев, когда данные намеренно подобраны злоумышленником, знающим хеш-функцию.

Сложность операций со словарями

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

my_dict = {'a': 1, 'b': 2, 'c': 3}

# O(1) операции
my_dict['d'] = 4        # Вставка/обновление
value = my_dict['a']    # Доступ
del my_dict['b']        # Удаление
'a' in my_dict          # Проверка ключа

# O(n) операции
list(my_dict.keys())    # Создание списка ключей
list(my_dict.values())  # Создание списка значений
'value' in my_dict.values()  # Поиск по значениям

Вычисление сложности на практике

Метод 1. Анализ вложенных циклов

# O(n²) — квадратичная сложность
def find_pairs_quadratic(items):
    pairs = []
    for i in range(len(items)):          # O(n)
        for j in range(i + 1, len(items)):  # O(n)
            pairs.append((items[i], items[j]))  # O(1)
    return pairs

# O(n) — линейная сложность
def count_unique(items):
    seen = set()
    for item in items:                   # O(n)
        seen.add(item)                   # O(1)
    return len(seen)                     # O(1)

Сложности вложенных циклов перемножаются, а сложности участков, следующих подряд, складываются: один цикл по всем элементам даёт \( O(n) \), а цикл, вложенный в цикл, \( O(n^2) \). Оценивать следует не отступы, а суть: вызов item not in some_list внутри цикла также является скрытым вложенным циклом, хотя выглядит как одна строка.

Метод 2. Учёт дорогостоящих операций

Вложенные циклы видны сразу, а вызовы библиотечных функций остаются незаметными. sorted стоит \( O(n \log n) \), list(...) и sum(...) обходятся в \( O(n) \), min и max также в \( O(n) \). При разборе функции эти стоимости подставляются и складываются.

def process_data(data):
    result = []
    
    # Сортировка: O(n log n)
    sorted_data = sorted(data)           # O(n log n)
    
    # Поиск каждого элемента: O(n) × O(log n) = O(n log n)
    for target in sorted_data:           # O(n)
        # Бинарный поиск: O(log n)
        # (предположим, что у нас есть реализация)
        index = binary_search(sorted_data, target)
        result.append(index)
    
    return result

# Общая сложность: O(n log n) + O(n log n) = O(n log n)

Метод 3. Практическое измерение

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

from timeit import timeit

print(f"{'размер':>8} {'время, мкс':>12} {'отношение':>10}")
prev = None
for size in [10_000, 20_000, 40_000, 80_000, 160_000]:
    setup = f"data = list(range({size}))"
    # вставляем и тут же удаляем, чтобы список не рос за время замера
    t = timeit("data.insert(0, -1); data.pop(0)", setup=setup, number=2000) / 2000
    ratio = f"{t / prev:.1f}x" if prev else "—"
    print(f"{size:8} {t * 1e6:12.1f} {ratio:>10}")
    prev = t

  размер   время, мкс  отношение
   10000          4.4          —
   20000          8.0        1.8x
   40000         15.7        2.0x
   80000         33.1        2.1x
  160000         62.0        1.9x

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

Если проделать то же самое с append, окажется, что время вызова не зависит от размера.

Практические правила для выбора коллекций

Область применения списков

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

Список плохо приспособлен к работе с началом: insert(0, x) и pop(0), требующие сдвига всего хвоста, стоят \(O(n)\) каждая. На больших данных это превращается в квадратичное время; там требуется дек, рассмотренный в главе про структуры данных и приспособленный к работе с обоими концами.

Область применения множеств

Множество применяется ради проверки принадлежности. Она стоит \(O(1)\) против \(O(n)\) у списка. Фильтрация миллиона событий по списку разрешённых идентификаторов займёт минуты, а через множество — доли секунды. Попутно множество удаляет дубликаты и поддерживает объединение, пересечение и разность.

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

Область применения словарей

Словарь необходим там, где у данных есть естественный ключ, будь то имя канала, номер события или дата измерения. Поиск по ключу стоит \(O(1)\), поэтому словарь заменяет перебор списка везде, где приходится искать запись, у которой поле равно заданному значению. На нём же удобно группировать, отводя под ключ категорию, а под значение список объектов, попадающих в неё.

С версии Python 3.7 словарь сохраняет порядок вставки. Поиск по значению словарь не поддерживает: такой поиск стоит \(O(n)\). Если он требуется часто, имеет смысл завести второй словарь с обратным отображением.

Оптимизация на практике

Если по коллекции многократно выполняется поиск, её лучше преобразовать в множество или словарь один раз до цикла. Построение множества имеет тот же порядок \( O(m) \), что и один линейный поиск, хотя и с большей константой, поэтому оно окупается после нескольких поисков: \( n \) проверок обходятся в \( O(n + m) \) вместо \( O(n \cdot m) \).

# ПЛОХО: O(n²)
def find_common_elements_slow(list1, list2):
    result = []
    for item in list1:           # O(n)
        if item in list2:        # O(m) - линейный поиск!
            result.append(item)
    return result

# ХОРОШО: O(n + m)
def find_common_elements_fast(list1, list2):
    set2 = set(list2)            # O(m) - создание множества
    result = []
    for item in list1:           # O(n)
        if item in set2:         # O(1) - поиск в хеш-таблице!
            result.append(item)
    return result

Некоторые правила сложности

1. O(1) < O(log n) < O(n) < O(n log n) < O(n²) — эту иерархию необходимо запомнить.
2. Особого внимания требуют вложенные циклы, дающие O(n²): внутренний цикл часто скрыт за вызовом наподобие x in list.
3. Структура подбирается под операцию: множества и словари для поиска, списки для последовательного перебора, дек для работы с обоих концов.

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

Задание. Решить задачи с разбором сложности: «Решение задач на Python и анализ сложности».

Функции

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

Слайды к главе. Материал главы изложен также в первых четырёх частях лекции «Функции в Python» (функция как объект, аргументы, области видимости, функциональный стиль), продолжение лекции относится к главе «Декораторы и functools»; слайды лекции доступны на сайте книги и в PDF.

Синтаксис объявления функций

Базовый синтаксис

Имя функции в Python может содержать буквы, цифры и символ подчёркивания _, но не может начинаться с цифры. Буквы допускаются из любого алфавита (PEP 3131), однако принято использовать латиницу и английские слова: PEP 8 требует этого от стандартной библиотеки и рекомендует открытым проектам.

def foo():
    return 42

foo()  # возвращает 42

Оператор return не является обязательным, и функция, обходящаяся без него, возвращает None.

def foo():
    42

print(foo())  # выводит None

Если хотя бы одна ветвь функции возвращает значение, PEP 8 требует единообразия: остальные ветви также завершаются явным return, при необходимости return None, и тогда отсутствие результата видно как предусмотренное.

Документирование функций

Для документирования используются строковые литералы (docstring), расположенные первыми в теле функции.

def foo():
    """I return 42."""
    return 42

Документация доступна через атрибут __doc__ или функцию help().

foo.__doc__  # 'I return 42.'
help(foo)    # показывает документацию

Для научного кода принят формат строк документации NumPy: после краткого описания следуют разделы Parameters (имя, тип, смысл и единицы измерения каждого параметра), Returns (тип и смысл результата), Raises (возбуждаемые исключения) и Examples (вызовы с ожидаемым выводом в формате интерактивной оболочки). Так документированы NumPy, SciPy и Astropy, а генератор документации Sphinx с расширением numpydoc собирает из таких строк справочник.

def kinetic_energy(m, v):
    """Кинетическая энергия тела.

    Parameters
    ----------
    m : float
        Масса, кг.
    v : float
        Скорость, м/с.

    Returns
    -------
    float
        Энергия, Дж.

    Examples
    --------
    >>> kinetic_energy(2.0, 3.0)
    9.0
    >>> kinetic_energy(1.0, 1.0)
    0.5
    """
    return m * v ** 2 / 2

Раздел Examples проверяется автоматически. Модуль doctest находит в строках документации фрагменты, начинающиеся с >>>, выполняет их и сравнивает вывод с записанным. Команда python3 -m doctest phys.py ничего не выводит, если все примеры сошлись, а с ключом -v печатает подробный отчёт. Если в формуле пропущено деление на два, отчёт указывает на расхождение.

Failed example:
    kinetic_energy(2.0, 3.0)
Expected:
    9.0
Got:
    18.0

Пример с известным ответом (тело массой 2 кг при скорости 3 м/с обладает энергией 9 Дж) одновременно документирует функцию и проверяет её формулу. Вывод сравнивается как текст, поэтому для вещественных результатов подбирают точно представимые ответы, такие как 9.0 и 0.5, или печатают округлённое значение. Расхождение документации с кодом обнаруживается при очередном запуске doctest, и его включают в проверки проекта наравне с тестами.

Функция как объект

Инструкция def создаёт объект класса function и связывает его с именем. Функции в Python являются объектами первого класса: функцию связывают со вторым именем, хранят в списке или словаре, передают в аргументе другой функции и возвращают из функции. Интегратору scipy.integrate.quad(f, a, b) безразлично, как устроена переданная функция f, вычисляет ли она формулу или интерполирует таблицу: он лишь вызывает её в выбранных им точках.

Объект функции хранит сведения о ней в атрибутах.

Аннотации типов

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

def mean(xs: list[float], w: list[float] | None = None) -> float:
    ...

mean.__annotations__
# {'xs': list[float], 'w': list[float] | None, 'return': <class 'float'>}

Синтаксис аннотаций появился в Python 3.0 (PEP 3107), их смысл как подсказок типов закрепил PEP 484 вместе с модулем typing (Python 3.5). С версии 3.9 встроенные коллекции указываются как list[float] без импорта из typing (PEP 585), с 3.10 объединение типов записывается через вертикальную черту: float | None (PEP 604). В Python 3.14 аннотации вычисляются отложенно, при первом обращении (PEP 649 и 749).

Интерпретатор аннотации сохраняет, но не проверяет. Вызов area("2") для функции area(r: float), возводящей радиус в квадрат, выполняется, и ошибка TypeError возникает уже внутри тела, на возведении строки в степень. Соответствие типов проверяют статические анализаторы mypy и pyright, а редакторы кода используют аннотации для подсказок. Единицы измерения аннотации не выражают, их по-прежнему указывают в документации.

Работа с аргументами

Позиционные и именованные аргументы

Аргументы могут передаваться двумя способами, свободно сочетаемыми в одном вызове. Позиционные разбираются по порядку, именованные — по имени параметра, поэтому их порядок роли не играет.

def min_of(x, y):
    return x if x < y else y

min_of(-5, 12)        # -5
min_of(x=-5, y=12)    # -5
min_of(y=12, x=-5)    # -5 (порядок не важен)

Функция названа min_of, а не min, чтобы не закрывать встроенную min (см. правило LEGB ниже). Позиционные аргументы следуют первыми. Запись min_of(x=-5, 12) недопустима и завершается ошибкой SyntaxError: positional argument follows keyword argument: интерпретатор не может определить, к какому параметру относится 12.

Упаковка позиционных аргументов

Произвольное количество аргументов принимает *args: звёздочка перед именем параметра собирает все лишние позиционные аргументы в кортеж под этим именем.

def min_of(*args):
    res = float("inf")
    for arg in args:
        if arg < res:
            res = arg
    return res

min_of(-5, 12, 13)  # -5
min_of()            # inf

При вызове без аргументов args представляет собой пустой кортеж, цикл не выполняется, и функция возвращает начальное значение, хотя минимума у пустого набора нет. Чтобы гарантировать хотя бы один аргумент, его выносят в отдельный обязательный параметр, расположенный перед *args.

def min_of(first, *args):
    res = first
    for arg in args:
        if arg < res:
            res = arg
    return res

min_of()  # TypeError: min_of() missing 1 required positional argument: 'first'

Распаковка аргументов

Звёздочка работает и в обратную сторону, разбирая в месте вызова готовую последовательность на отдельные аргументы. Подходит любой итерируемый объект: список, кортеж, множество или генератор.

xs = {-5, 12, 13}
min_of(*xs)           # -5
min_of(*[-5, 12, 13]) # -5
min_of(*(-5, 12, 13)) # -5

С Python 3.5 (PEP 448) звёздочек в одном вызове может быть несколько, и между ними допускаются обычные аргументы: min_of(*xs, 0, *ys).

Параметры после *args и значения по умолчанию

Всё, что записано в объявлении после *args, может быть передано только по имени, поскольку позиции для этих параметров уже исчерпаны. Таким образом оформляются необязательные настройки со значением по умолчанию, которое вызывающая сторона изменяет явно.

def bounded_min(first, *args, lo=float("-inf"), hi=float("inf")):
    res = None
    for arg in (first,) + args:
        if lo <= arg <= hi and (res is None or arg < res):
            res = arg
    return res

bounded_min(-5, 12, 13, lo=0, hi=255)  # 12
bounded_min(-5, lo=0, hi=255)          # None

Из трёх чисел в отрезок [0, 255] попадают 12 и 13, минимальное из них равно 12; значение −5 отброшено как выходящее за нижнюю границу, которую задаёт параметр lo. Если в отрезок не попадает ни одно число, функция возвращает None: любое число в качестве ответа было бы неотличимо от настоящего минимума.

Опасность изменяемых значений по умолчанию

Значение по умолчанию вычисляется один раз, при выполнении инструкции def, а не при каждом вызове, и хранится в атрибуте функции __defaults__. Для числа или строки это незаметно, но изменяемый объект, созданный однажды, окажется общим для всех вызовов и будет накапливать состояние между ними.

def unique(iterable, seen=set()):
    acc = []
    for item in iterable:
        if item not in seen:
            seen.add(item)
            acc.append(item)
    return acc

xs = [1, 1, 2, 3]
unique(xs)  # [1, 2, 3]
unique(xs)  # [] 😱
unique.__defaults__  # ({1, 2, 3},)

Второй вызов на тех же данных возвращает пустой список, поскольку множество seen уже содержит все числа с предыдущего вызова, что и показывает __defaults__. В объявлении указывается None, а настоящее множество создаётся внутри функции при каждом вызове.

def unique(iterable, seen=None):
    seen = set() if seen is None else set(seen)
    acc = []
    for item in iterable:
        if item not in seen:
            seen.add(item)
            acc.append(item)
    return acc

xs = [1, 1, 2, 3]
unique(xs)  # [1, 2, 3]
unique(xs)  # [1, 2, 3] ✅

Переданная коллекция копируется в новое множество, и объект вызывающей стороны не изменяется. Проверка is None надёжнее распространённой записи seen or []: оператор or подставляет значение по умолчанию вместо любого ложного значения. Настройка k = k or 1.0 без сообщения об ошибке превратит переданный коэффициент 0.0 в 1.0, а для массива NumPy из нескольких элементов завершится ошибкой ValueError, поскольку истинность такого массива не определена.

Только именованные параметры

Можно потребовать, чтобы некоторые аргументы передавались только по имени. Одиночная звёздочка без имени отделяет такие параметры, не собирая лишних позиционных аргументов (PEP 3102).

def flatten(xs, *, depth=None):
    pass

flatten([1, [2], 3], depth=1)  # ✅
flatten([1, [2], 3], 1)        # TypeError

Так оформляют настройки расчёта. По вызову integrate(g, 0, 1, 1e-6, 100) не понять, где допуск, а где число узлов, тогда как запись integrate(g, 0, 1, tol=1e-6, n=100) понятна без документации, а ошибочный позиционный вызов завершается TypeError.

Только позиционные параметры

Обратное ограничение задаёт косая черта: параметры, записанные до /, передаются только по позиции (PEP 570, Python 3.8). Имена таких параметров не входят в интерфейс функции и могут меняться без последствий для вызывающего кода; так объявлены многие встроенные функции, например len(obj, /).

def f(a, b, /, c, *args, d=1, **kw):
    return a, b, c, args, d, kw

f(1, 2, 3)                  # (1, 2, 3, (), 1, {})
f(1, 2, 3, 4, 5, d=6, e=7)  # (1, 2, 3, (4, 5), 6, {'e': 7})
f(1, 2, c=3)                # (1, 2, 3, (), 1, {})

def g(a, /):
    return a

g(a=1)  # TypeError: g() got some positional-only arguments passed as keyword arguments: 'a'

Сигнатура f содержит все виды параметров в обязательном порядке: только позиционные, обычные, *args, только именованные, **kw.

Упаковка именованных аргументов

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

def runner(cmd, **kwargs):
    if kwargs.get("verbose", True):
        print("Logging enabled")

runner("mysqld", limit=42)                    # ✅
runner("mysqld", **{"verbose": False})        # ✅
options = {"verbose": False}
runner("mysqld", **options)                   # ✅

Имена args и kwargs являются соглашением, а не требованием языка: значение имеют только звёздочки. Сочетание обеих даёт универсальную обёртку def wrapper(*args, **kwargs): return f(*args, **kwargs), которая передаёт любые аргументы без изменений; на ней построены декораторы.

Распаковка и присваивание

Базовая распаковка

Распаковка работает в любом присваивании. Слева записывается структура, составленная из имён, справа располагается итерируемый объект, и Python раскладывает второе по первому, причём форма слева может повторять вложенность справа.

x, y, z = [1, 2, 3]           # ✅
x, y, z = {1, 2, 3}           # ✅ (но порядок не гарантирован!)
x, y, z = "xyz"               # ✅

# Распаковка вложенных структур
rectangle = (0, 0), (4, 4)
(x1, y1), (x2, y2) = rectangle

С множеством код выполнится, но число, попавшее в x, не определено, поскольку порядка у множества нет.

Расширенная распаковка (Python 3.0+)

Звёздочка слева от знака равенства собирает «всё остальное» в список (PEP 3132). Имя, помеченное ею, может располагаться в начале, в конце или в середине; Python сначала распределяет значения по обычным именам, а остаток, не разобранный ими, достаётся звёздочке.

first, *rest = range(1, 5)           # first=1, rest=[2, 3, 4]
first, *rest, last = range(1, 5)     # first=1, rest=[2, 3], last=4

# Можно использовать в любом месте
*_, (first, *rest) = [range(1, 5)] * 5

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

first, *rest, last = [42]  # ValueError

Строка файла данных вида «время, номер канала, отсчёты» разбирается одним присваиванием: t, ch, *counts = line.split().

Распаковка в цикле for

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

for a, *b in [range(4), range(2)]:
    print(b)
# Вывод:
# [1, 2, 3]
# [1]

Распаковка в литералах (Python 3.5+)

Звёздочки допускаются и внутри литералов коллекций (PEP 448): одна звёздочка раскладывает последовательность, две — словарь.

old, new = [1, 2], (3, 4)
points = [*old, *new]          # [1, 2, 3, 4]

defaults = {"n": 1000, "rule": "simpson"}
user = {"n": 10_000}
config = {**defaults, **user}  # {'n': 10000, 'rule': 'simpson'}

При совпадении ключей сохраняется значение из правого словаря, поэтому пользовательские настройки перекрывают значения по умолчанию; с Python 3.9 то же записывается как defaults | user.

Области видимости (Scopes)

Функции внутри функций

Функции в Python относятся к объектам первого класса, а потому их определяют внутри других функций, передают в аргументах, возвращают как результат. def, вложенный в def, представляет собой обычное присваивание, только локальное.

def wrapper():
    def identity(x):
        return x
    return identity

f = wrapper()
f(42)  # 42

Правило LEGB

Интерпретатор ищет имя в четырёх областях по порядку и останавливается на первой найденной:

• Local (локальная), имена, объявленные внутри самой функции.
• Enclosing (объемлющая), имена объемлющей функции, если эта вложена в другую.
• Global (глобальная), имена уровня модуля.
• Built-in (встроенная), имена, доступные всегда, например len, print и min.

min = 42  # global

def f(*args):
    min = 2  # enclosing
    def g():
        min = 4  # local
        print(min)

Здесь три разных min; g печатает свой, локальный. Если из g удалить строку с присваиванием, печататься начнёт min, объявленный в f; если удалить её и оттуда, будет напечатана глобальная 42. Поэтому переменные не называют именами встроенных функций: встроенный min, последнее звено цепочки, оказывается закрытым. Ошибка проявляется далеко от места присваивания: после len = 5 вызов len("abc") завершается ошибкой TypeError: 'int' object is not callable.

Замыкания и позднее связывание

Имя, которое функция не определяет сама, разрешается не при объявлении, а в момент вызова; это называется поздним связыванием. Функция f ниже не знает, откуда возьмётся i, и при каждом вызове обращается к значению, находящемуся под этим именем в текущий момент.

def f():
    print(i)

for i in range(4):
    f()
# Вывод:
# 0
# 1
# 2
# 3

Замыкания здесь ещё нет: i является обычным глобальным именем. Замыкание возникает, когда вложенная функция использует имя, взятое из объемлющей, и продолжает использовать его даже после того, как та завершилась.

def make_adder(step):
    def add(x):
        return x + step      # step взят из объемлющей функции
    return add

add5 = make_adder(5)
print(add5(10))                          # 15
print(add5.__closure__[0].cell_contents) # 5 — значение хранится в ячейке замыкания

Функция make_adder давно завершилась, её локальные переменные должны были исчезнуть, но step сохраняется благодаря add, ссылающейся на него. На этом механизме построены декораторы, рассматриваемые в главе «Декораторы и functools». Той же схемой пользуются для моделей с параметрами: фабрика make_gaussian(mu, sigma) возвращает функцию одной переменной x с закреплёнными параметрами распределения, пригодную для интегрирования и построения графика. Для подгонки curve_fit, наоборот, модель принимает подбираемые параметры аргументами: model(x, mu, sigma).

Позднее связывание и замыкания вместе образуют ловушку. Функции, созданные в цикле, захватывают переменную, а не значение, записанное в ней, и после цикла все они видят последнее значение.

funcs = [lambda: i for i in range(3)]
print([f() for f in funcs])          # [2, 2, 2], а не [0, 1, 2]

funcs = [lambda i=i: i for i in range(3)]
print([f() for f in funcs])          # [0, 1, 2]

Во втором варианте значение фиксируется аргументом по умолчанию, вычисляемым, в отличие от тела функции, сразу при её создании. Тот же результат дают functools.partial, закрепляющий значения аргументов в момент создания, и фабрика функций, создающая на каждый вызов отдельную ячейку замыкания. При переборе параметров физической модели ловушка не сопровождается сообщением об ошибке: список моделей, построенный в цикле лямбдами и вызываемый после цикла, вычисляет всё с последним значением параметра, и ошибка видна только по совпадению результатов. Лямбда, вызванная в той же итерации, например интеграл quad(lambda x: s * x, 0, 1) внутри цикла по s, вычисляется верно.

Присваивание и области видимости

Чтение имени возможно из любой внешней области, а присваивание всегда создаёт локальную переменную. Решение принимается при компиляции функции и распространяется на всё её тело, поэтому min += 1 завершается ошибкой не на присваивании, а на попытке прочитать локальную min, ещё не получившую значения; начиная с Python 3.11 сообщение звучит как cannot access local variable 'min' where it is not associated with a value, в прежних версиях — local variable 'min' referenced before assignment.

min = 42

def f():
    min += 1  # UnboundLocalError!
    return min

Оператор global

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

min = 42

def f():
    global min
    min += 1
    return min

f()  # 43
f()  # 44

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

Оператор nonlocal (Python 3+)

nonlocal выполняет то же самое, но для объемлющей функции, а не для модуля (PEP 3104). Именно он позволяет вложенной функции присвоить новое значение переменной той функции, в которую она вложена; на этом основаны счётчики и накопители внутри декораторов.

def cell(value=None):
    def get():
        return value
    def set(update):
        nonlocal value
        value = update
    return get, set

get, set = cell()
set(42)
get()  # 42

Две функции разделяют одну переменную value, существующую столько же, сколько они сами. Интерпретатор хранит её в ячейке, на которую ссылается кортеж get.__closure__; помимо get и set, к ней обращаются только через этот служебный атрибут, предназначенный для отладки: get.__closure__[0].cell_contents.

Функциональное программирование

Анонимные функции (lambda)

Функцию в одну строку, передаваемую в sorted или map, задаёт lambda. Её тело представляет собой одно выражение, и его значение становится результатом без return.

lambda arguments: expression

# Эквивалентно:
def <lambda>(arguments):
    return expression

Список параметров у лямбды такой же, как у обычной функции, со звёздочками и значениями по умолчанию.

lambda x: x ** 2
lambda foo, *args, bar=None, **kwargs: 42

Как только логика перестаёт умещаться в одну строку, ей дают имя через def. PEP 8 рекомендует всегда использовать def вместо присваивания лямбды имени: запись f = lambda x: ... ничем не лучше def f(x): ..., но у такой функции нет строки документации, а в трассировке ошибки вместо имени стоит <lambda>.

Функции map, filter, zip

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

map применяет функцию к каждому элементу, поступающему из источника.

list(map(lambda x: x % 7, [1, 9, 16, -1, 2, 5]))  # [1, 2, 2, 6, 2, 5]

filter оставляет только элементы, для которых функция вернула истину. Если вместо функции передать None, фильтр отсеет всё ложное: нули, пустые коллекции и пустые строки.

list(filter(lambda x: x % 2 != 0, range(10)))  # [1, 3, 5, 7, 9]

# С None - оставляет только truthy значения
xs = [0, None, [], {}, set(), "", 42]
list(filter(None, xs))  # [42]

zip проходит по нескольким последовательностям параллельно и на каждом шаге возвращает кортеж, составленный из их элементов. Останавливается он по самой короткой, и лишние элементы длинных последовательностей теряются; с Python 3.10 параметр strict=True превращает несовпадение длин в ошибку ValueError.

list(zip("abc", range(3), [42j, 42j, 42j]))
# [('a', 0, 42j), ('b', 1, 42j), ('c', 2, 42j)]

Функцию в аргументе принимают и другие встроенные функции. sorted, min и max упорядочивают и выбирают элементы по функции-ключу key, а any и all прекращают перебор, как только результат известен. Модуль operator содержит готовые ключи: itemgetter выбирает элемент по индексу или ключу словаря, attrgetter — атрибут объекта.

from operator import itemgetter

events = [{"id": 1, "energy": 3.2}, {"id": 2, "energy": 7.9}]
max(events, key=itemgetter("energy"))  # {'id': 2, 'energy': 7.9}

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

Включения коллекций

То же самое записывается через включения. Форма ниже читается как «взять x ** 2 для каждого x из range(10), если x нечётно». Второй пример показывает ту же операцию через map и filter. Два for подряд разворачивают вложенную структуру в плоский список; их порядок такой же, как во вложенных циклах.

[x ** 2 for x in range(10) if x % 2 == 1]  # [1, 9, 25, 49, 81]

# Эквивалент с map/filter:
list(map(lambda x: x ** 2, filter(lambda x: x % 2 == 1, range(10))))

# Вложенные включения:
nested = [range(5), range(8, 10)]
[x for xs in nested for x in xs]  # [0, 1, 2, 3, 4, 8, 9]

Тот же синтаксис применяется для множеств и словарей, отличаются только скобки. Фигурные скобки с одним выражением дают множество, и в первом примере совпавшие между собой остатки объединились; а с парой, разделённой двоеточием, получается словарь.

{x % 7 for x in [1, 9, 16, -1, 2, 5]}  # {1, 2, 5, 6}

date = {"year": 2014, "month": "September", "day": ""}
{k: v for k, v in date.items() if v}  # {'year': 2014, 'month': 'September'}

{x: x ** 2 for x in range(4)}  # {0: 0, 1: 1, 2: 4, 3: 9}

Во втором примере условие if v отбрасывает записи с пустым значением, и здесь действует та же истинность объектов, применяемая и в filter(None, ...).

map остаётся уместен с готовой функцией: list(map(float, fields)) короче включения [float(s) for s in fields]. Выражение-генератор в круглых скобках вычисляет значения по одному и не строит промежуточный список: sum(x * x for x in data) суммирует квадраты, не выделяя память под список квадратов. Генераторы рассматриваются в главе «Итераторы, генераторы и корутины».

Чистые функции

Чистой называют функцию, результат которой зависит только от аргументов и которая не имеет побочных эффектов: не изменяет аргументы, глобальные переменные и файлы. Такую функцию проще проверять, поскольку тест не требует подготовки окружения; её результат можно запомнить и не вычислять повторно, как делает functools.lru_cache; её вызовы выполняются параллельно без блокировок.

total = 0.0

def add_sample(x):     # нечистая: изменяет глобальное состояние
    global total
    total += x

def mean(xs):          # чистая
    return sum(xs) / len(xs)

Программа целиком из чистых функций не состоит: чтение данных и запись результатов являются побочными эффектами. Расчётное ядро удобно держать чистым, а ввод и вывод сосредоточить на его границе. Для моделирования со случайными числами это означает передачу генератора аргументом: функция, использующая глобальный генератор, даёт разные результаты при каждом запуске, а генератор numpy.random.default_rng(42), созданный с фиксированным зерном и переданный в функцию, делает расчёт воспроизводимым. Чистой такая функция не становится, поскольку каждый вызов меняет состояние генератора, но её результат определяется аргументами, включая генератор.

Параметры модели для интеграторов

Интеграторы, оптимизаторы и решатели SciPy ожидают функцию одной переменной (или вектора), а модель обычно зависит ещё и от параметров. Закрепить параметры можно несколькими способами.

import math
from functools import partial
from scipy.integrate import quad

def gauss(x, mu, sigma):
    return math.exp(-(x - mu) ** 2 / (2 * sigma ** 2))

quad(gauss, -5, 5, args=(0.0, 1.0))             # параметр args
quad(lambda x: gauss(x, 0.0, 1.0), -5, 5)       # лямбда
quad(partial(gauss, mu=0.0, sigma=1.0), -5, 5)  # partial

Многие функции SciPy (quad, minimize, solve_ivp) принимают дополнительные аргументы в параметре args и передают их вызываемой функции после основных переменных. Лямбда подставляет параметры при каждом вызове: литералы — как записаны, имена — по значению на момент вызова. functools.partial закрепляет значения при создании и, в отличие от лямбды, сериализуется модулем pickle, если сериализуемы исходная функция и закреплённые аргументы; это требуется при распараллеливании через multiprocessing, и сама функция при этом определяется в импортируемом модуле (см. главу «Многопоточность и GIL»). Замыкание или фабрика функций уместны, когда модель содержит собственную логику или состояние, но pickle их не сериализует.

Стоимость вызова функции

Вызов функции в Python имеет собственную стоимость: интерпретатор создаёт кадр, связывает аргументы и возвращает результат. Замеры python3 -m timeit на Python 3.12 для списка xs из 100 тысяч чисел и функции sq = lambda x: x * x показывают порядок этих затрат.

Вызов функции добавил около 10 нс на элемент: 2,66 мс против 1,64 мс. Соотношение map и включения с вызовом зависит от версии интерпретатора: в других версиях map бывает быстрее. Встроенная sum в четыре-пять раз быстрее явного цикла, поскольку её цикл выполняется в функции на C, без исполнения байт-кода для каждого элемента. Отсюда не следует, что функций нужно избегать: 10 нс заметны только в цикле по миллионам элементов. Участок, на который приходится основное время работы, переносят во встроенные функции или в векторные операции NumPy, обрабатывающие весь массив одним вызовом; подробно это рассматривается в главе «Оптимизация средствами самого Python».

PEP 8 и стиль кода

Код читают чаще, чем пишут, и единый стиль экономит время всем участникам. PEP 8 является официальным соглашением о том, как выглядит код на Python; его соблюдение проверяют линтеры, например pycodestyle и ruff.

Базовые рекомендации

• 4 пробела для отступов, задающих структуру блока
• Максимум 79 символов в строке кода (72 символа для комментариев и строк документации)
• lower_case_with_underscores для переменных и функций
• UPPER_CASE_WITH_UNDERSCORES для констант

Выражения и операторы

Пробелы вокруг операторов расставляются по приоритету, чтобы структура выражения была видна визуально. Тело if переносится на новую строку, поскольку однострочную запись труднее заметить при беглом чтении. Отрицание принадлежности записывается оператором not in, а не через not ... in: PEP 8 формулирует это правило для is not, а линтеры распространяют его и на in. Сравнение принято записывать в естественном порядке, с проверяемой переменной слева от значения. PEP 8 прямо этого не оговаривает, однако обратный порядок, так называемые условия Йоды, в Python не нужен: в C он защищает от случайного присваивания if (x = 5), а в Python присваивание = внутри условия является синтаксической ошибкой.

exp = -1.05
value = (item_value / item_count) * offset / exp
hypot2 = x*x + y*y

if bar:
    x += 1

if method == 'md5':
    pass

if key not in d:
    pass

Ниже приведены те же четыре конструкции в нерекомендуемой записи.

value = ( item_value/item_count )*offset/exp

if bar: x += 1

if 'md5' == method:
    pass

if not key in d:
    pass

Функции

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

def something_useful(arg, **options):
    """One-line summary.

    Optional longer description.
    """
    pass

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

def scale(x, factor=2.0): ...
def scale(x: float, factor: float = 2.0) -> float: ...

Резюме

• Функция является объектом: её передают в аргументах, хранят и возвращают; аннотации документируют типы, но не проверяются
• Функции принимают произвольное количество позиционных (*args) и именованных (**kwargs) аргументов; параметры до / передаются только по позиции, после * — только по имени
• Синтаксис распаковки работает в вызовах функций, присваивании, циклах и литералах коллекций
• Имена ищутся по правилу LEGB: локальная, объемлющая, глобальная, встроенная область
• Присваивание создаёт локальную переменную; поведение, заданное по умолчанию, изменяется через global и nonlocal
• Значение по умолчанию вычисляется один раз, при выполнении def, поэтому изменяемым оно быть не должно
• Для функций, созданных в цикле, значение фиксируют параметром по умолчанию, partial или фабрикой
• Python поддерживает элементы функционального программирования: lambda, map, filter, zip, включения коллекций
• Вызов функции стоит порядка 10 нс, что заметно только в циклах по миллионам элементов
• PEP 8 описывает, как должен выглядеть читаемый код, и правила, записанные в нём, проверяются линтерами

Итераторы, генераторы и корутины

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

Эти механизмы позволяют обрабатывать файлы, не помещающиеся в память, и описывать бесконечные последовательности. Из генераторов выросла и асинхронность Python: первые корутины asyncio были генераторами, а нативные корутины async def используют тот же механизм приостановки функции. Сам asyncio рассматривается в главе, посвящённой асинхронности.

Слайды к главе. Материал главы изложен также в лекции «Итераторы, генераторы и корутины» (итераторы, генераторы, модуль itertools, сопрограммы, async и await) с демонстрациями в интерактивной оболочке; слайды лекции доступны на сайте книги и в PDF.

Итераторы

Устройство цикла for

Цикл for в Python не перебирает индексы: он получает у объекта итератор функцией iter и вызывает для него next, пока тот не сообщит об окончании исключением StopIteration. Исключение перехватывает сам цикл, поэтому в коде оно не видно. Тот же цикл, записанный явно:

xs = [1.5, 2.5, 4.0]

it = iter(xs)
while True:
    try:
        x = next(it)
    except StopIteration:
        break
    print(x)

Встроенные функции iter и next вызывают специальные методы __iter__ и __next__, как len вызывает __len__. По тому же протоколу работают распаковка, списковые включения, функции sum, max, sorted и list и конструкторы коллекций. В байт-коде цикл представлен двумя инструкциями: GET_ITER вызывает iter для перебираемого объекта, FOR_ITER на каждом шаге вызывает next и при окончании элементов переходит за конец цикла.

import dis

dis.dis('for x in xs: pass')

  0           0 RESUME                   0

  1           2 LOAD_NAME                0 (xs)
              4 GET_ITER
        >>    6 FOR_ITER                 2 (to 14)
             10 STORE_NAME               1 (x)
             12 JUMP_BACKWARD            4 (to 6)
        >>   14 END_FOR
             16 RETURN_CONST             0 (None)

Вывод получен в Python 3.12; набор инструкций меняется от версии к версии, но пара GET_ITER и FOR_ITER присутствует во всех.

Итерируемый объект и итератор

Протокол итерации разделяет две роли. Итерируемый объект (iterable) обладает методом __iter__, который при каждом вызове возвращает новый итератор. Итератор (iterator) обладает методом __next__, возвращающим следующий элемент или возбуждающим StopIteration, когда элементы закончились, и методом __iter__, возвращающим сам итератор. Итератор обязан быть и итерируемым, поэтому его можно передать в цикл for.

Встроенные коллекции — списки, кортежи, словари, множества, строки — являются итерируемыми объектами; файл, открытый функцией open, сам является итератором по строкам. По списку можно пройти сколько угодно раз, поскольку каждый цикл получает новый итератор, а по итератору — один раз: после первого прохода он исчерпан. Исчерпанный итератор обязан и дальше возбуждать StopIteration при каждом вызове next.

xs = [1.5, 2.5, 4.0]
it = iter(xs)
next(it), next(it)    # (1.5, 2.5)
next(it)              # 4.0
next(it)              # исключение StopIteration
iter(it) is it        # True: итератор возвращает самого себя
list(it), list(xs)    # ([], [1.5, 2.5, 4.0])
next(range(3))        # TypeError: 'range' object is not an iterator

Проверка isinstance(x, collections.abc.Iterator) отличает итератор от итерируемого объекта, у которого есть только __iter__.

Собственный итератор

Класс Linspace ниже — упрощённый аналог numpy.linspace: n равноотстоящих точек отрезка от a до b. Роли разделены явно: контейнер хранит параметры сетки и на каждый вызов __iter__ создаёт новый итератор, а обход выполняет класс LinspaceIterator.

class Linspace:
    def __init__(self, a, b, n):
        self.a, self.n = a, n
        self.h = (b - a) / (n - 1)

    def __iter__(self):
        return LinspaceIterator(self.a, self.h, self.n)

class LinspaceIterator:
    def __init__(self, a, h, n):
        self.a, self.h, self.n, self.i = a, h, n, 0   # состояние обхода

    def __iter__(self):
        return self                # итератор обязан быть итерируемым

    def __next__(self):
        if self.i == self.n:
            raise StopIteration
        self.i += 1
        return self.a + (self.i - 1) * self.h

grid = Linspace(0.0, 1.0, 5)
list(grid)    # [0.0, 0.25, 0.5, 0.75, 1.0]
list(grid)    # тот же результат: второй проход получает новый итератор

Счётчик i хранится в итераторе, а не в контейнере, поэтому каждый новый for начинает с первой точки, а по одной сетке можно пройти произвольное число раз. Точка вычисляется как a + i·h, а не прибавлением h к предыдущей: при накоплении ошибки округления складываются и растут с номером точки, а при умножении погрешность каждой точки остаётся в последних разрядах. Последняя точка и при умножении может отличаться от b в последнем знаке, поэтому numpy.linspace присваивает ей значение b явно.

Обе роли можно совместить в одном классе, где __iter__ возвращает self: кода при этом меньше, однако второй проход начнётся там, где закончился первый, и окажется пустым. Так устроены однопроходные объекты — файлы и генераторы; у контейнеров роли разделены. Без метода __iter__ сам итератор не является итерируемым: цикл for по контейнеру Linspace работает, поскольку у полученного итератора цикл вызывает только __next__, а цикл по объекту iter(grid) и передача его в list или zip завершаются TypeError.

Другие способы итерации

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

Если у объекта нет __iter__, но есть __getitem__, функция iter создаёт итератор, запрашивающий элементы с индексами 0, 1, 2 и далее, пока __getitem__ не возбудит IndexError. Так перебирались последовательности до появления протокола итераторов, и этот путь сохранён для совместимости. collections.abc.Iterable такой объект итерируемым не признаёт, поэтому надёжная проверка — вызов iter(obj).

class Squares:
    def __getitem__(self, i):
        if i >= 4:
            raise IndexError(i)
        return i * i

list(Squares()), 9 in Squares()   # ([0, 1, 4, 9], True)

Функция iter с двумя аргументами принимает вызываемый объект и граничное значение: итератор вызывает функцию без аргументов и выдаёт результаты, пока не получит граничное значение. Двоичные файлы оцифровщиков и детекторов читаются так блоками фиксированного размера; границей служит пустая строка байтов, которую read возвращает в конце файла.

from functools import partial

with open('run042.dat', 'rb') as f:
    for block in iter(partial(f.read, 4096), b''):
        process(block)

Оператор in вызывает метод __contains__, а при его отсутствии перебирает объект через __iter__ или __getitem__, пока не найдёт равный элемент. Для итератора это означает расход элементов: после проверки в нём остаются только элементы после найденного.

it = iter(Linspace(0.0, 1.0, 5))
0.5 in it      # True
list(it)       # [0.75, 1.0]: элементы до 0.5 включительно израсходованы

Итераторы стандартной библиотеки

range не хранит элементы, а вычисляет их и при этом остаётся последовательностью с длиной, индексами и проверкой in без перебора для целых чисел. Представления словаря отражают его текущее содержимое; изменение размера словаря во время обхода завершается RuntimeError: dictionary changed size during iteration. Функции map, filter, zip, enumerate и reversed возвращают итераторы и вычисляют элементы по запросу, поэтому их результат, использованный дважды, во второй раз пуст — частая ошибка при переносе кода с Python 2, где map и zip возвращали списки.

m = map(str, [1, 2])
list(m), list(m)                      # (['1', '2'], [])
list(zip([1, 2], [1], strict=True))   # ValueError: zip() argument 2 is shorter than argument 1

Функция zip останавливается на самой короткой последовательности; с Python 3.10 параметр strict=True превращает расхождение длин в ValueError. При объединении отметок времени и показаний zip(times, values, strict=True) защищает от молчаливого усечения рядов разной длины.

Генераторы

Генераторная функция

Писать два класса ради простого перебора избыточно. Функция, в теле которой встречается yield, при вызове не выполняет тело, а возвращает объект-генератор. Генератор — итератор: next запускает тело и выполняет его до ближайшего yield, значение yield становится результатом next, а функция приостанавливается. Генератор хранит кадр функции — локальные переменные и место остановки — между вызовами next; точку остановки задаёт yield. Следующий next продолжает выполнение с инструкции после yield.

def countdown(n):
    print('старт')
    while n > 0:
        yield n
        n -= 1
    return 'пуск'

g = countdown(3)    # тело не выполняется, ничего не печатается
next(g)             # печатает «старт», возвращает 3
next(g), next(g)    # (2, 1)
next(g)             # исключение StopIteration: пуск

Когда тело завершается, возбуждается StopIteration, и значение return, если оно есть, сохраняется в атрибуте value исключения; цикл for и функция list это значение не используют: list(countdown(3)) печатает «старт» и возвращает [3, 2, 1]. Генератор заменяет класс итератора: метод __iter__, написанный генератором, возвращает новый генератор при каждом вызове, и по контейнеру можно проходить многократно без отдельного класса.

class Linspace:
    def __init__(self, a, b, n):
        self.a, self.n = a, n
        self.h = (b - a) / (n - 1)

    def __iter__(self):
        for i in range(self.n):
            yield self.a + i * self.h

Генератор удобен там, где следующий элемент вычисляется по предыдущим, — шаги интегрирования, итерации метода Ньютона, последовательные приближения.

Состояния генератора

Генератор проходит четыре состояния, которые возвращает функция inspect.getgeneratorstate.

import inspect

g = countdown(3)
inspect.getgeneratorstate(g)                       # 'GEN_CREATED'
next(g)                                            # печатает «старт», возвращает 3
inspect.getgeneratorstate(g), g.gi_frame.f_locals  # ('GEN_SUSPENDED', {'n': 3})

Состояние хранится в атрибутах объекта: gi_frame — кадр выполнения с локальными переменными f_locals и номером строки f_lineno, после завершения генератора gi_frame равен None; gi_running — признак выполнения; gi_yieldfrom — подгенератор, которому делегировано выполнение через yield from. Методы send, throw и close рассматриваются в разделе о корутинах; close у ещё не запущенного генератора переводит его в GEN_CLOSED сразу, без выполнения тела. Генератор не может запустить сам себя: next(g) внутри тела g завершается ValueError: generator already executing.

Генераторные выражения

Генераторное выражение — краткая форма генератора; от спискового включения его отличают круглые скобки вместо квадратных. Если выражение — единственный аргумент функции, вторые скобки не нужны.

squares = [x * x for x in range(100_000)]   # список строится сразу
lazy = (x * x for x in range(100_000))      # генератор, элементы по запросу
total = sum(x * x for x in range(100_000))  # скобки вызова служат скобками выражения

Списковое включение хранит все элементы, генератор не вычисляет ни одного, пока элемент не будет запрошен. Измерения на Python 3.12.3:

sys.getsizeof учитывает только сам список, то есть массив ссылок; объекты-числа добавляют ещё около 2,8 МБ, что и показывает пик памяти при суммировании. Размер генератора не зависит от длины последовательности, но зависит от версии Python: в 3.11 тот же генератор занимает 208 байт.

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

data = [0, 2, 5, 12]
threshold = 1
g = (x for x in data if x > threshold)
threshold = 10
list(g)          # [12]: условие прочитало threshold в момент перебора

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

Конвейер генераторов

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

def read_lines(path):
    with open(path) as f:
        yield from f

def parse(lines):
    for line in lines:
        if not line.strip() or line.startswith('#'):
            continue           # пустые строки и комментарии пропускаются
        t, channel, value = line.split()
        yield float(t), channel, float(value)

def select(events, name):
    for t, channel, value in events:
        if channel == name:
            yield t, value

lines = read_lines('run042.log')
bpm = select(parse(lines), 'BPM01')
print(max(value for t, value in bpm))

read_lines читает журнал построчно, поскольку файл — итератор по строкам; parse пропускает пустые строки и комментарии и выдаёт разобранные события; select оставляет события одного канала; max потребляет результат. Элементы проходят конвейер по одному: max запрашивает событие у select, select — у parse, parse — строку у read_lines. В памяти одновременно находятся одна строка и одно событие, поэтому журнал любого размера обрабатывается с постоянным расходом памяти. Стадии независимы: их легко заменить, добавить проверку или пересчёт единиц, а parse и select проверяются по отдельности на списке строк вместо файла.

log = ['0.0 BPM01 1.2', '0.1 BPM02 0.7', '0.2 BPM01 1.4']
pipe = select(parse(log), 'BPM01')   # ничего не прочитано
next(pipe)                           # (0.0, 1.2)
next(pipe)                           # (0.2, 1.4): строка BPM02 отброшена
next(pipe, 'конец')                  # 'конец' вместо StopIteration

Файл закрывается, когда генератор read_lines завершится или будет закрыт; если обход прерван досрочно, файл остаётся открытым до вызова close или сборки мусора (раздел «Завершение генератора»).

Бесконечные последовательности

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

import itertools, math

def oscillator(x, v, dt, w=1.0):
    t = 0.0
    while True:
        yield t, x, v
        v -= w * w * x * dt
        x += v * dt
        t += dt

states = oscillator(1.0, 0.0, 0.01)
list(itertools.islice(states, 3))   # три первых состояния
next(states)                        # четвёртое, t = 0.03: генератор продолжает с места остановки
next(t for t, x, v in oscillator(1.0, 0.0, 0.01) if x < 0)   # 1.5700000000000012
math.pi / 2                                                  # 1.5707963267948966

Условия остановки в генераторе нет: его задаёт вызывающий код. itertools.islice берёт заданное число состояний и больше не обращается к генератору, takewhile выдаёт состояния, пока выполняется условие, next с генераторным выражением возвращает первое состояние, удовлетворяющее условию, например первое пересечение нуля. takewhile при этом забирает из генератора и первый элемент, не прошедший условие, и этот элемент теряется. Список из бесконечного генератора построить нельзя: list(oscillator(...)) не завершится, а память будет расти, пока процесс не будет остановлен.

Координата впервые становится отрицательной при t = 1,57 при точном значении π/2 = 1,5708: расхождение меньше шага. Полунеявная схема точно сохраняет величину x² + v² − dt·x·v, поэтому x² + v² колеблется в узкой полосе около единицы: за 10 000 шагов отклонение не превышает dt/(2 − dt) ≈ 0,00503. У явной схемы Эйлера x² + v² на каждом шаге умножается на 1 + dt², и за те же 10 000 шагов выросла бы примерно в e раз. Так генератор разделяет схему интегрирования и условие остановки — по времени, по числу шагов или по событию.

Моменты времени, вычисляемые сложением t += dt, тоже накапливают ошибку округления: у itertools.count(0.0, 0.1) десятый шаг даёт 0.9999999999999999 вместо 1.0, и документация itertools рекомендует в таком случае умножение. Генератор моментов времени без накопления:

def clock(dt):
    """Бесконечная последовательность моментов времени с шагом dt."""
    for i in itertools.count():
        yield i * dt           # умножение, а не накопление t += dt

[round(t, 3) for t in itertools.islice(clock(0.02), 5)]   # [0.0, 0.02, 0.04, 0.06, 0.08]

Делегирование: yield from

Когда генератор лишь передаёт элементы другого итерируемого объекта, цикл for x in g: yield x записывается короче: yield from g. Рекурсивный обход двоичного дерева поиска в порядке возрастания выдаёт элементы левого поддерева, значение узла и элементы правого поддерева, а вложенные вызовы соединяются через yield from.

class Node:
    def __init__(self, value, left=None, right=None):
        self.value = value
        self.left, self.right = left, right

def walk(node):
    if node is not None:
        yield from walk(node.left)
        yield node.value
        yield from walk(node.right)

tree = Node(5, Node(3, Node(1)), Node(8))
list(walk(tree))     # [1, 3, 5, 8]

Конструкция yield from (PEP 380, Python 3.3) не сводится к сокращению цикла. Она передаёт во вложенный генератор значения, отправленные через send, и исключения, отправленные через throw, а значением самого выражения yield from становится результат return вложенного генератора:

def sub():
    yield 1
    yield 2
    return 'итог'

def outer():
    r = yield from sub()
    print('подгенератор вернул', r)

list(outer())   # печатает «подгенератор вернул итог», результат [1, 2]

Это позволяет разбивать сложный генератор на части, как функцию на подфункции. Рекурсивным генератором с yield from записывается обход любых деревьев — разбиений пространства (квадродеревья и октодеревья в задаче N тел), иерархий геометрии детектора.

Завершение генератора

До Python 3.7 исключение StopIteration, возникшее внутри тела генератора, — например, от вызова next у исчерпанного итератора, — молча завершало генератор, и ошибка терялась. PEP 479 изменил это поведение: такое исключение превращается в RuntimeError. Поэтому внутри генератора next вызывается со значением по умолчанию или в блоке try, а для завершения используется return.

def firsts(groups):
    for g in groups:
        yield next(iter(g))        # пустая группа: RuntimeError

list(firsts([[1], []]))   # RuntimeError: generator raised StopIteration

def firsts(groups):
    for g in groups:
        yield next(iter(g), None)

list(firsts([[1], []]))   # [1, None]

Генератор, обход которого прерван досрочно — оператором break или исключением у потребителя, — остаётся в состоянии GEN_SUSPENDED; его блоки finally и менеджеры контекста выполнятся при вызове close или при уничтожении объекта сборщиком мусора. В CPython это обычно происходит сразу после потери последней ссылки, в других реализациях — позже, поэтому ресурсы освобождают явно: g.close() или contextlib.closing(g).

Модуль itertools

Модуль itertools содержит ленивые итераторы, реализованные на C, — базовые средства обработки последовательностей без промежуточных списков. Все функции модуля возвращают итераторы, поэтому их результат однопроходный и может быть входом следующей функции.

Бесконечные итераторы и срезы

count считает от start с шагом step, в том числе для вещественных чисел, но с вещественным шагом накапливает его сложением; cycle повторяет элементы источника по кругу, сохраняя их копию; repeat выдаёт одно значение заданное или бесконечное число раз. islice — аналог среза для любого итератора без отрицательных индексов, поскольку длина итератора неизвестна. takewhile останавливается на первом ложном условии, dropwhile пропускает элементы, пока условие истинно, а после первого неподходящего выдаёт всё остальное без проверки: это не фильтр.

Объединение и группировка

chain.from_iterable соединяет источники из итерируемого объекта, например из списка списков; распаковка chain(*xss) строит кортеж источников и на бесконечном источнике не завершится. groupby выдаёт пары «ключ, итератор группы» и объединяет только соседние элементы, поэтому для группировки по всему набору данные сначала сортируют по тому же ключу.

from itertools import groupby, pairwise, batched, accumulate

events = [('BPM02', 0.7), ('BPM01', 1.2), ('BPM01', 1.4), ('BPM02', 0.9)]
[name for name, _ in groupby(events, key=lambda e: e[0])]
# ['BPM02', 'BPM01', 'BPM02']: без сортировки BPM02 попал в две группы
for name, grp in groupby(sorted(events), key=lambda e: e[0]):
    print(name, [v for _, v in grp])   # BPM01 [1.2, 1.4] и BPM02 [0.7, 0.9]

times = [0.00, 0.12, 0.31, 0.39]
[round(b - a, 2) for a, b in pairwise(times)]   # [0.12, 0.19, 0.08]
list(batched(range(7), 3))                      # [(0, 1, 2), (3, 4, 5), (6,)]
list(accumulate([3, 1, 4, 1, 5], max))          # [3, 3, 4, 4, 5]

pairwise по отметкам времени даёт интервалы между событиями, accumulate — накопленную дозу или интеграл методом прямоугольников, batched — пакеты для записи в файл или отправки по сети. Вместо pairwise иногда пишут zip(xs, islice(xs, 1, None)); на списке это работает, а на итераторе даёт неверные пары, поскольку оба аргумента расходуют один итератор.

Комбинаторика

Комбинаторные функции заменяют вложенные циклы: product выдаёт декартово произведение в лексикографическом порядке, где последний источник меняется быстрее всех. Число вариантов растёт быстро, поэтому его заранее оценивают функциями math.perm и math.comb (Python 3.8).

from itertools import product, combinations
import math

grid = list(product([1.0, 2.0], [0.1, 0.2, 0.3]))
len(grid), grid[:3]          # (6, [(1.0, 0.1), (1.0, 0.2), (1.0, 0.3)])
list(combinations('ABCD', 2))
# [('A', 'B'), ('A', 'C'), ('A', 'D'), ('B', 'C'), ('B', 'D'), ('C', 'D')]
math.comb(32, 2), sum(1 for _ in combinations(range(32), 2))   # (496, 496)

product перебирает сетку параметров моделирования — температуры и поля, энергии и углы — одним циклом без вложенности; combinations даёт пары детекторов для поиска совпадений: 32 детектора образуют 496 пар. Число повторов в product передаётся только именованным аргументом repeat: вызов product('ab', 2) завершается TypeError.

Рецепты и ограничения

Документация модуля содержит раздел рецептов — коротких функций, собранных из стандартных блоков: скользящее окно sliding_window, чередование источников roundrobin, удаление повторов unique_everseen и другие; многие из них вошли в сторонний пакет more-itertools. Скользящее среднее строится на deque ограниченной длины: очередь хранит последние n отсчётов, а старые вытесняются автоматически.

from collections import deque
from itertools import islice

def moving_average(xs, n):
    it = iter(xs)
    window = deque(islice(it, n - 1), maxlen=n)
    for x in it:
        window.append(x)
        yield sum(window) / n

list(moving_average([1, 2, 3, 4, 5], 3))   # [2.0, 3.0, 4.0]

Ограничения модуля следуют из ленивости:

• product, permutations и combinations читают входные источники целиком и сохраняют их в кортежах ещё до выдачи первого результата, поэтому бесконечный итератор передавать в них нельзя;
• tee хранит элементы, пока их не прочитают все копии, и при большом отставании одной копии расходует память как список; исходный итератор после tee не используется;
• группа из groupby действительна только до перехода к следующей: если её нужно сохранить, её сразу превращают в список;
• islice не поддерживает отрицательные индексы.

Скользящее среднее и медиана — простейшие фильтры сигнала; для массивов NumPy среднее вычисляют свёрткой numpy.convolve, медиану — функцией scipy.signal.medfilt, а генератор подходит для потока, который не хранится целиком.

Корутины

Корутины (сопрограммы) выросли из генераторов: генератор, принимающий значения через send, хранит состояние между вызовами и обрабатывает поток входных данных. На том же механизме приостановки построена асинхронность, где один поток занимается другой работой, пока задача ожидает ответа от сети или прибора.

Метод send

Выражение yield справа от присваивания делает генератор двусторонним: x = yield result выдаёт result наружу, приостанавливает функцию и при возобновлении получает значение, переданное методом send. Вызов next(g) равносилен g.send(None). Перед первым send корутину запускают вызовом next, чтобы она дошла до первого yield: отправить значение в только что созданный генератор нельзя. Метод send возвращает следующее значение, выданное корутиной, поэтому один вызов и передаёт измерение, и возвращает обновлённый результат.

Корутина stats вычисляет среднее и дисперсию потока измерений по формулам Уэлфорда: на каждом шаге обновляются число отсчётов, среднее и сумма квадратов отклонений M2, а несмещённая оценка дисперсии равна M2/(n − 1).

def stats():
    n, mean, m2 = 0, 0.0, 0.0
    result = None
    while True:
        x = yield result
        n += 1
        d = x - mean
        mean += d / n
        m2 += d * (x - mean)
        result = n, mean, m2 / (n - 1) if n > 1 else 0.0

s = stats()
s.send(2.0)    # TypeError: can't send non-None value to a just-started generator
next(s)        # запуск до первого yield
s.send(2.0)    # (1, 2.0, 0.0)
s.send(4.0)    # (2, 3.0, 2.0)
s.send(6.0)    # (3, 4.0, 4.0)

Состояние хранится в локальных переменных генератора, а не в атрибутах объекта; эквивалентный класс с методом add длиннее, но при сложном состоянии нагляднее. Формулы Уэлфорда численно устойчивы: в отличие от формулы «среднее квадратов минус квадрат среднего», они не вычитают близкие большие числа и не теряют точность при большом постоянном смещении сигнала.

Тот же приём с аннотацией типов: тип Generator[тип выдачи, тип приёма, тип возврата] из collections.abc описывает корутину, выдающую None или результат, принимающую вклад и ничего не возвращающую. Корутина ниже вычисляет вклад с учётом сложных процентов; коэффициент роста вычисляется один раз — при первом next(coro), когда корутина доходит до первого yield, — и далее не меняется, а суммы вклада в неё можно передавать неограниченно.

from collections.abc import Generator

def cash_return_coro(percent: float,
                     years: int) -> Generator[float | None, float, None]:
    value = (1 + percent / 100) ** years
    result = None
    while True:
        try:
            deposit = yield result
        except GeneratorExit:
            print('Выход из корутины')
            raise
        result = round(deposit * value, 2)

coro = cash_return_coro(5, 5)
next(coro)                       # запуск до первого yield
for item in [1000, 2000, 5000, 10000, 100000]:
    print(coro.send(item))       # 1276.28, 2552.56, 6381.41, 12762.82, 127628.16
coro.close()                     # печатает «Выход из корутины»

Выражение deposit = yield result отдаёт наружу результат предыдущего шага и принимает следующий вклад, поэтому next(coro) нужен один раз — чтобы довести корутину до первого yield. Форма с двумя yield за оборот — один принимает вклад, другой отдаёт результат — требует вызова next после каждого send: если его пропустить, следующий вклад попадёт не в тот yield и потеряется без ошибки.

Методы throw и close

throw возбуждает исключение в точке, где генератор приостановлен, — так, будто его выбросила инструкция yield. Если генератор перехватывает исключение, он продолжает работу до следующего yield, и throw возвращает выданное значение; если нет, исключение выходит наружу из вызова throw. В счётчике ниже ValueError служит командой сброса.

def counter():
    n = 0
    try:
        while True:
            try:
                yield n
                n += 1
            except ValueError:
                n = 0
    finally:
        print('закрытие, n =', n)

c = counter()
next(c), next(c), next(c)   # (0, 1, 2)
c.throw(ValueError)         # 0: сброс без завершения генератора
next(c)                     # 1
c.close()                   # печатает «закрытие, n = 1»
next(c)                     # исключение StopIteration

close возбуждает в точке остановки GeneratorExit: генератор обязан завершиться — выполнить блоки finally и выйти. Если вместо этого он снова выполнит yield, возникнет RuntimeError: generator ignored GeneratorExit. Поэтому после перехвата GeneratorExit генератор не выполняет yield: исключение возбуждают повторно, как в cash_return_coro, или завершают генератор оператором return, а для освобождения ресурсов достаточно finally или with. CPython вызывает close и при уничтожении незавершённого генератора, поэтому файлы и соединения, открытые в теле генератора, закрываются и при прерванном обходе. Форма throw с тремя аргументами — тип, значение, трассировка — с Python 3.12 устарела: передаётся один аргумент — экземпляр или класс исключения.

yield from как канал

yield from соединяет вызывающий код с подгенератором напрямую: значения, выдаваемые подгенератором, проходят наружу, значения send и исключения throw — внутрь, а делегирующий генератор на это время приостановлен и лишь получает итоговый результат.

def averager():
    total, n = 0.0, 0
    while True:
        x = yield
        if x is None:
            return total / n
        total, n = total + x, n + 1

def collect(results, name):
    while True:
        results[name] = yield from averager()

results = {}
c = collect(results, 'BPM01')
next(c)
for x in (1.25, 1.5, 1.75):
    c.send(x)
c.send(None)       # конец серии
results            # {'BPM01': 1.5}

Корутина averager принимает значения одной серии и по сигналу конца серии — значению None — возвращает среднее; делегирующий генератор collect записывает этот результат в словарь и начинает следующую серию. Для вызывающего кода два уровня неразличимы: он отправляет значения в collect, а они попадают в averager. Без yield from пришлось бы вручную перехватывать StopIteration, передавать send и throw и обрабатывать close. На такой передаче управления по цепочке вложенных генераторов была построена первая версия asyncio: корутины ожидали друг друга через yield from, пока в Python 3.5 не появился await.

Генератор как менеджер контекста

Декоратор contextlib.contextmanager превращает генератор с одним yield в менеджер контекста. Код до yield выполняется при входе в блок with и играет роль __enter__; значение yield связывается с переменной после as; код после yield выполняется при выходе из блока и играет роль __exit__.

import contextlib, time

@contextlib.contextmanager
def timer(label):
    t0 = time.perf_counter()
    try:
        yield
    finally:
        dt = time.perf_counter() - t0
        print(f'{label}: {dt:.2f} с')

with timer('сумма'):
    s = sum(i * i for i in range(10**6))   # печатает «сумма: 0.04 с»; время зависит от машины

with timer('деление'):
    1 / 0      # печатает «деление: 0.00 с», затем ZeroDivisionError выходит наружу

Если в блоке with возникает исключение, оно возбуждается в генераторе в точке yield, поэтому завершающий код помещается в finally — иначе при ошибке он не выполнится. Исключение, перехваченное в генераторе и не возбуждённое повторно, считается обработанным. Такой менеджер короче класса с методами __enter__ и __exit__ и подходит для однократных действий вокруг блока: замер времени этапов обработки, временная смена каталога или настроек, захват и освобождение ресурса. Менеджер из contextmanager применяется и как декоратор функции. В contextlib есть и готовые менеджеры: suppress подавляет указанные исключения, chdir (Python 3.11) временно меняет рабочий каталог, closing вызывает close по выходе, ExitStack собирает переменное число менеджеров; временный каталог создаёт tempfile.TemporaryDirectory.

От генераторов к async и await

Цикл событий на генераторах

Планировщик, переключающийся между задачами, записывается в десяток строк, если задачи — генераторы. Задача выполняет шаг работы и отдаёт управление инструкцией yield. Планировщик хранит очередь готовых задач, берёт первую, продвигает её вызовом next до следующего yield и ставит в конец очереди; завершившаяся задача возбуждает StopIteration и из очереди удаляется.

from collections import deque

def task(name, n):
    for i in range(n):
        print(name, 'шаг', i)
        yield

def run(tasks):
    queue = deque(tasks)
    while queue:
        t = queue.popleft()
        try:
            next(t)
        except StopIteration:
            continue
        queue.append(t)

run([task('прибор A', 3), task('прибор B', 2)])

прибор A шаг 0
прибор B шаг 0
прибор A шаг 1
прибор B шаг 1
прибор A шаг 2

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

async def и await

До Python 3.5 корутины asyncio были генераторами: они ожидали друг друга через yield from и помечались декоратором @asyncio.coroutine, удалённым в Python 3.11. PEP 492 ввёл нативные корутины: функция, объявленная через async def, при вызове возвращает объект типа coroutine, а await приостанавливает её до завершения ожидаемого объекта — другой корутины, задачи или Future. await допустим только внутри async def, а объект-корутину нельзя перебрать циклом for.

Ожидание приборов с разной задержкой показывает разницу между ожиданием и блокировкой:

import asyncio, time

async def poll(name, delay):
    await asyncio.sleep(delay)      # точка ожидания: управление у цикла событий
    return name, delay

async def blocking(name, delay):
    time.sleep(delay)               # блокирующий вызов: цикл событий стоит
    return name, delay

async def main(f):
    t0 = time.perf_counter()
    res = await asyncio.gather(f('A', 0.3), f('B', 0.5), f('C', 0.8))
    print(res, round(time.perf_counter() - t0, 2))

asyncio.run(main(poll))       # [('A', 0.3), ('B', 0.5), ('C', 0.8)] 0.8
asyncio.run(main(blocking))   # [('A', 0.3), ('B', 0.5), ('C', 0.8)] 1.61

С await задержки перекрываются, и общее время равно наибольшей — 0,8 с; time.sleep не отдаёт управление циклу событий, и опросы выполняются по очереди за 1,6 с. Вызов poll('A', 0.3) без await ничего не выполняет: создаётся объект, а при его уничтожении выводится предупреждение RuntimeWarning: coroutine 'poll' was never awaited — признак забытого await. Задачи, тайм-ауты, группы задач и асинхронная итерация рассматриваются в главе «Асинхронность».

Выбор средства

Итоги

Таким образом, цикл for получает итератор функцией iter и вызывает next, пока тот не возбудит StopIteration; итерируемый объект выдаёт новый итератор на каждый проход, а сам итератор однопроходный. Функция с yield возвращает генератор, выполняемый по шагам: между вызовами локальные переменные и место остановки хранятся в кадре, а return завершает генератор и передаёт значение в StopIteration. Генераторные выражения и конвейеры генераторов обрабатывают данные по одному элементу, поэтому расход памяти не зависит от объёма данных. Модуль itertools даёт ленивые бесконечные итераторы, срезы, объединение, группировку и комбинаторику. Методы send, throw и close превращают генератор в корутину, а yield from соединяет её с подгенератором и возвращает его результат. Нативные корутины async def и await выполняет цикл событий, переключая задачи в точках ожидания.

Для самостоятельного изучения рекомендуются документация модуля itertools с разделом рецептов, PEP 380 (yield from), PEP 479 (StopIteration внутри генератора) и PEP 492 (async и await).

Декораторы и модуль functools

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

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

Слайды к главе. Материал главы изложен также в пятой и шестой частях лекции «Функции в Python» (декораторы и модуль functools) с демонстрациями в интерактивной оболочке; слайды лекции доступны на сайте книги и в PDF.

Синтаксис декораторов

Декоратор представляет собой вызываемый объект, чаще всего функцию, принимающий другую функцию и возвращающий новую (или любой другой объект). Символ @ перед определением является синтаксическим сахаром, не добавляющим возможностей, но выносящим имя декоратора на видное место перед функцией.

@decorator
def foo(x):
    return 42

Эквивалентно:

def foo(x):
    return 42

foo = decorator(foo)

После применения декоратора имя foo ссылается на результат вызова decorator(foo). Эквивалентность практическая: выражение после @ вычисляется до создания функции, а имя foo с исходной функцией не связывается ни в какой момент. Декоратор выполняется один раз, вместе с инструкцией def, то есть при импорте или запуске модуля, а не при каждом вызове функции. Синтаксис @ появился в Python 2.4 (PEP 318); с версии 3.9 после @ допускается любое выражение, а не только имя или вызов (PEP 614).

В научном коде декораторы встречаются постоянно: @numba.njit компилирует функцию в машинный код, @functools.lru_cache запоминает результаты, @pytest.fixture объявляет подготовку данных для тестов.

Устройство простого декоратора

Рассмотрим устройство на примере декоратора trace, печатающего каждый вызов функции. Декоратор получает исходную функцию в func и определяет новую, inner; та принимает аргументы в самом общем виде *args, **kwargs, применимом к любой функции; inner выполняет свою работу, передаёт управление оригиналу и возвращает полученный результат. Наружу декоратор возвращает inner.

def trace(func):
    def inner(*args, **kwargs):
        print(func.__name__, args, kwargs)
        return func(*args, **kwargs)
    return inner

func остаётся доступной внутри inner даже после завершения trace: это замыкание, рассмотренное в главе про функции.

Применим его.

@trace
def identity(x):
    "I do nothing useful."
    return x

identity(42)  # Вывод: identity (42,) {} → 42

Проблема атрибутов функции

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

identity.__name__  # 'inner'
help(identity)     # Справка о inner, а не identity

Помимо неудобства при отладке, это нарушает работу всего, что опирается на имена функций, от автоматически собираемой документации до фреймворков, ищущих обработчики по имени.

Спасение через functools.wraps

functools.wraps является декоратором, копирующим в обёртку метаданные оригинала: __module__, __name__, __qualname__, __doc__ и __annotations__ (с Python 3.12 также __type_params__). Словарь атрибутов оригинала __dict__ дописывается в словарь обёртки, а ссылка на исходную функцию помещается в __wrapped__. При написании собственного декоратора над внутренней функцией всегда ставится @functools.wraps(func).

import functools

def trace(func):
    @functools.wraps(func)
    def inner(*args, **kwargs):
        print(func.__name__, args, kwargs)
        return func(*args, **kwargs)
    return inner

Теперь identity.__name__ и help(identity) возвращают данные оригинала, а inspect.signature(identity), следуя по ссылке __wrapped__, показывает сигнатуру (x) вместо (*args, **kwargs). Та же ссылка позволяет вызвать исходную функцию в обход декоратора, а inspect.unwrap снимает всю цепочку обёрток. Ещё одно следствие касается сериализации: без wraps декорированную функцию нельзя передать модулю pickle, поскольку обёртка называется trace.<locals>.inner, а с wraps можно, что важно для передачи функций в процессы multiprocessing.

Декораторы с аргументами

Иногда декоратор необходимо настроить, например указать trace, куда выводить. Здесь появляется третий уровень вложенности. Запись @trace(sys.stderr) означает два действия: сначала вызывается trace(sys.stderr), и только полученный результат применяется к функции как декоратор, а значит, trace возвращает декоратор, который уже возвращает обёртку.

import sys


def trace(handle):
    def decorator(func):
        @functools.wraps(func)
        def inner(*args, **kwargs):
            print(func.__name__, args, kwargs, file=handle)
            return func(*args, **kwargs)
        return inner
    return decorator

@trace(sys.stderr)
def identity(x):
    return x

Эквивалентно:

decorator = trace(sys.stderr)
identity = decorator(identity)

Декораторы с опциональными аргументами

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

def trace(func=None, *, handle=sys.stdout):
    if func is None:
        return lambda func: trace(func, handle=handle)
    if not callable(func):
        raise TypeError("настройки trace передаются по имени: trace(handle=...)")

    @functools.wraps(func)
    def inner(*args, **kwargs):
        print(func.__name__, args, kwargs, file=handle)
        return func(*args, **kwargs)
    return inner

Использование:

@trace
def foo(): ...

@trace(handle=sys.stderr)
def bar(): ...

Звёздочка делает handle параметром, передаваемым только по имени, и настройка записывается как @trace(handle=sys.stderr). От ошибочной записи @trace(sys.stderr) звёздочка не защищает: файловый объект, переданный позиционно, всё равно попадает в func. Без проверки декоратор принял бы файл за декорируемую функцию и вернул бы обёртку, а уже при декорировании, когда эта обёртка получит identity вместо аргументов, возникла бы ошибка AttributeError с сообщением, не указывающим на причину. Проверка callable(func) превращает эту ситуацию в понятный TypeError.

Значение sys.stdout по умолчанию вычисляется при выполнении def, поэтому перенаправление contextlib.redirect_stdout, выполненное позже, печать trace не затрагивает: она уходит в исходный поток. Если это важно, по умолчанию указывают handle=None, а sys.stdout подставляют при вызове.

Полезные декораторы на практике

Декоратор @timethis для замера времени

Декоратор для измерения времени выполняет функцию n_iter раз и печатает лучший результат, а не средний. Среднее искажается любой случайной помехой наподобие переключения задач операционной системой, а минимум показывает, на что код способен в отсутствие помех. По той же причине в стандартной библиотеке предусмотрен timeit.repeat, возвращающий список измерений, из которого берётся min. Сам timeit.timeit минимума не вычисляет и возвращает суммарное время всех запусков, которое приходится самостоятельно делить на их число.

import time

def timethis(func=None, *, n_iter=100):
    if func is None:
        return lambda func: timethis(func, n_iter=n_iter)

    @functools.wraps(func)
    def inner(*args, **kwargs):
        print(func.__name__, end=" ... ")
        acc = float("inf")
        for i in range(n_iter):
            tick = time.perf_counter()
            result = func(*args, **kwargs)
            acc = min(acc, time.perf_counter() - tick)
        print(acc)
        return result
    return inner

Декоратор @once для однократного вызова

Существует работа, которая выполняется один раз, сколько бы раз функция ни вызывалась: чтение конфигурации, установка соединения, разбор большого справочника. @once запоминает результат первого вызова и в дальнейшем возвращает сохранённое значение.

Хранить состояние декоратор мог бы в замыкании, но здесь оно размещено на inner: функция также является объектом и допускает произвольные атрибуты. Флаг при этом виден извне, и some_func.called покажет, вызывалась функция или нет.

def once(func):
    @functools.wraps(func)
    def inner(*args, **kwargs):
        if not inner.called:
            inner.result = func(*args, **kwargs)
            inner.called = True
        return inner.result
    inner.called = False
    return inner

Для функции без аргументов то же поведение даёт готовый @functools.cache (Python 3.9), рассматриваемый ниже.

Декоратор @memoized и мемоизация

Мемоизация представляет собой запоминание результата отдельно для каждого набора аргументов. Функция ведёт словарь «аргументы → результат» и ничего не вычисляет повторно, если ответ уже сохранён. Ключом служит кортеж из позиционных аргументов и отсортированных именованных; сортировка необходима, чтобы f(a=1, b=2) и f(b=2, a=1) попали в одну ячейку.

def memoized(func):
    cache = {}
    mark = object()  # разделитель позиционных и именованных аргументов

    @functools.wraps(func)
    def inner(*args, **kwargs):
        key = args + (mark,) + tuple(sorted(kwargs.items()))
        if key not in cache:
            cache[key] = func(*args, **kwargs)
        return cache[key]
    return inner

Между двумя частями ключа стоит особый объект-разделитель mark. Без него вызовы f(1, ("a", 2)) и f(1, a=2) дали бы одинаковый ключ (1, ("a", 2)) и получили бы один результат на двоих; так же, отдельным маркером, разделяет части ключа и functools.lru_cache.

Ключом словаря может быть только хешируемый объект, поэтому такая мемоизация приведёт к ошибке, если в функцию передать список, словарь или множество. Ради универсальности аргументы сериализуют, например через pickle, но тогда теряется скорость. На практике проще применять мемоизацию только к функциям с простыми аргументами и использовать готовый functools.lru_cache, рассматриваемый ниже.

Декоратор @deprecated для устаревших функций

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

import warnings

def deprecated(func):
    @functools.wraps(func)
    def inner(*args, **kwargs):
        warnings.warn(
            f"{func.__name__} устарела и будет удалена",
            category=DeprecationWarning,
            stacklevel=2,      # показать строку вызывающего кода, а не эту
        )
        return func(*args, **kwargs)
    return inner

Предупреждение должно выдаваться при вызове функции, поэтому warnings.warn располагается внутри inner. Если вынести его в тело декоратора, предупреждение сработает один раз при импорте модуля и больше никогда: пользователь получит сообщение об устаревшей функции, возможно даже не вызванной им, а при настоящих вызовах не получит ничего.

Аргумент stacklevel=2 переводит указатель со строки внутри декоратора на ту, где функция вызвана, и относит предупреждение к модулю вызывающего кода. Без него место вызова по предупреждению найти невозможно, а при фильтре по умолчанию предупреждение не выводится вовсе.

DeprecationWarning по умолчанию скрыт везде, кроме кода модуля __main__ (PEP 565, Python 3.7). Чтобы увидеть его в собственном коде, интерпретатор запускают с ключом -W default или добавляют строку warnings.simplefilter("always", DeprecationWarning); ключ -W error::DeprecationWarning превращает такие предупреждения в исключения, что удобно в тестах.

С Python 3.13 стандартная библиотека содержит готовый декоратор warnings.deprecated (PEP 702). Он выдаёт то же предупреждение при вызове и вдобавок сообщает об устаревании статическим анализаторам типов.

from warnings import deprecated

@deprecated("old_api устарела, её заменяет new_api")
def old_api(): ...

Контрактное программирование с декораторами

Контрактное программирование состоит в том, чтобы описывать в самой функции условия, требуемые от входа, и обещания, даваемые на выходе. Проверка, добавленная декоратором рядом с объявлением, видна сразу, а тело функции свободно от проверок. Запишем два декоратора, @pre для предусловия и @post для постусловия. Оба принимают проверяющую функцию и текст сообщения: pre проверяет аргументы до вызова, post — результат после.

def pre(cond, message):
    def decorator(func):
        @functools.wraps(func)
        def inner(*args, **kwargs):
            assert cond(*args, **kwargs), message
            return func(*args, **kwargs)
        return inner
    return decorator

def post(cond, message):
    def decorator(func):
        @functools.wraps(func)
        def inner(*args, **kwargs):
            result = func(*args, **kwargs)
            assert cond(result), message
            return result
        return inner
    return decorator

Использование:

import math


@pre(lambda x: 0 < x < 1, "argument must be a fraction")
@post(lambda r: r < 0, "log of a fraction must be negative")
def log_fraction(x):
    return math.log(x)

Предусловие на физический смысл аргумента (доля в интервале от 0 до 1, положительная масса, температура выше абсолютного нуля) останавливает расчёт на входе функции с понятным сообщением, а не порождает nan, обнаруживаемый только в итоговом графике.

assert полностью исключается из кода, если интерпретатор запущен с ключом -O. Для контрактов внутри собственной программы это подходит: при отладке проверка выполняется, а в рабочем режиме не выполняется, и остаётся лишь вызов обёртки. Чтобы убрать и его, декоратор возвращает функцию без обёртки: return inner if __debug__ else func. Данные, поступившие извне, проверять через assert нельзя, там необходим явный raise.

Цепочки декораторов

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

@deco1
@deco2
def foo(): ...

Применяются они снизу вверх, ближайший к def — первым.

foo = deco1(deco2(foo))

Сами выражения после @ вычисляются сверху вниз, что заметно у декораторов с аргументами, а полученные декораторы применяются снизу вверх. При вызове управление передаётся в обратную сторону: сначала во внешний deco1, затем во внутренний deco2 и только потом в саму функцию. Поэтому @functools.lru_cache располагают выше проверок, чтобы попадание в кеш не расходовало время на валидацию, а @timethis располагают ниже, чтобы он измерял саму функцию, а не работу декораторов, применённых сверху.

Декораторы стандартной библиотеки

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

Декоратор применяется и к классу (PEP 3129): он получает класс и возвращает класс. Так устроен @dataclass, дописывающий по аннотациям полей методы __init__, __repr__ и __eq__; классы рассматриваются в главе «Классы».

Модуль functools

Рекурсия и предел глубины

Мемоизация особенно полезна для рекурсивных функций. Каждый рекурсивный вызов создаёт кадр стека со своими аргументами и локальными переменными, и кадры накапливаются, пока рекурсия не дойдёт до базового случая. Интерпретатор ограничивает глубину: sys.getrecursionlimit() по умолчанию возвращает 1000, и более глубокая рекурсия завершается ошибкой RecursionError.

def depth(n):
    return 0 if n == 0 else 1 + depth(n - 1)

depth(900)   # 900
depth(5000)  # RecursionError: maximum recursion depth exceeded

Предел поднимается функцией sys.setrecursionlimit, но это откладывает проблему, а не решает её. Хвостовую рекурсию Python не оптимизирует; это сознательное решение, сохраняющее полную трассировку ошибок. Поэтому глубокая рекурсия переписывается циклом, при необходимости со своим стеком в списке. Предел на практике достигается там, где глубина рекурсии равна размеру данных: рекурсивный поиск связного кластера на решётке (перколяция, кластерный алгоритм Вольфа для модели Изинга) или обход графа в глубину на решётке 100 × 100 легко превышает 1000 уровней, а итеративный обход со стеком из списка такого ограничения не имеет. Сама рекурсия рассмотрена в главе «Рекурсия и сортировки», обход графа в глубину — в главе «Графы».

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

def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)

Мемоизация с ограничением через lru_cache

Готовая замена рассмотренному выше @memoized. Кеш ограничен по размеру, и при переполнении из него вытесняется запись, к которой дольше всего не обращались, — так расшифровывается LRU, least recently used. Благодаря ограничению кеш не занимает всю память в долго работающей программе.

@functools.lru_cache(maxsize=128)
def expensive_func(x):
    return x * x

С Python 3.8 декоратор записывается и без скобок, @functools.lru_cache, с размером по умолчанию 128. Значение maxsize=None снимает ограничение, и так поступают только для функций с заведомо небольшим числом различных аргументов; с Python 3.9 то же записывается короче: @functools.cache. Метод cache_info() показывает число попаданий и промахов, cache_clear() очищает кеш, а параметр typed=True хранит аргументы разных типов, например 1 и 1.0, раздельно. Если попаданий почти нет, кеш только расходует память.

Ограничение то же, что у самописного варианта: аргументы обязаны быть хешируемыми, поэтому функцию от массива NumPy так не кешируют. В отличие от @memoized, именованные аргументы в ключе не сортируются, и вызовы f(a=1, b=2) и f(b=2, a=1) могут занять две записи кеша.

Кеш превращает экспоненциальную рекурсию для чисел Фибоначчи в линейную, поскольку каждое значение вычисляется однажды. Предел глубины мемоизация при этом не снимает: fib(2000) с пустым кешем завершается RecursionError, поэтому таблицу значений заполняют по возрастанию n или считают циклом.

@functools.cache
def fib(n):
    return n if n < 2 else fib(n - 1) + fib(n - 2)

fib(32)           # 2178309
fib.cache_info()  # CacheInfo(hits=30, misses=33, maxsize=None, currsize=33)

Без кеша вычисление fib(32) на Python 3.12 заняло около 0,15 с, с кешем — около 70 мкс.

Частичное применение через partial

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

f = functools.partial(sorted, key=lambda x: x[1])
f([('a', 4), ('b', 2)])  # [('b', 2), ('a', 4)]

int2 = functools.partial(int, base=2)
int2("1010")    # 10
int2.keywords   # {'base': 2}

У partial три преимущества перед лямбдой. Значения аргументов закрепляются в момент создания, поэтому ловушки позднего связывания нет. Объект partial сериализуется модулем pickle, если сериализуемы исходная функция и закреплённые аргументы, и потому передаётся в процессы через multiprocessing.Pool.map, где лямбда вызывает ошибку сериализации; исходная функция при этом определяется в импортируемом модуле, а не в ячейке блокнота (см. главу «Многопоточность и GIL»). Атрибуты func, args и keywords показывают, что именно закреплено. Интегратор quad ожидает функцию одной переменной, а функция Планка зависит от частоты и температуры: partial(planck, T=5800.0) закрепляет температуру.

С Python 3.14 объект functools.Placeholder позволяет закрепить не только первые позиционные аргументы: на его месте остаётся пропуск, заполняемый при вызове.

Обобщённые функции и singledispatch

Когда функция должна вести себя по-разному для разных типов, обычно применяется цепочка из isinstance. Она работает, но её приходится править всякий раз, когда появляется новый тип. С singledispatch базовая функция объявляется один раз, а реализации для конкретных типов регистрируются отдельно, в том числе из другого модуля.

@functools.singledispatch
def pack(obj):
    raise TypeError(f"Unsupported type: {type(obj)}")

@pack.register(int)
def _(obj):
    return b"I" + hex(obj).encode("ascii")

@pack.register(list)
def _(obj):
    return b"L" + b",".join(map(pack, obj))

Выбор реализации выполняется по типу первого аргумента, отсюда «single» в названии, причём с учётом наследования: для True выбирается реализация для int, поскольку bool является подклассом int. Зарегистрированные функции названы _, поскольку обращаться к ним напрямую не требуется: вызываться всегда будет базовая pack.

С Python 3.7 тип указывается и аннотацией первого параметра регистрируемой функции, без аргумента у register; с Python 3.11 в такой аннотации допускается объединение типов. Для методов классов предусмотрен functools.singledispatchmethod (Python 3.8).

@pack.register
def _(obj: str):
    return b"S" + obj.encode("utf-8")

Свёртка последовательности через reduce

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

functools.reduce(lambda acc, x: acc * x, [1, 2, 3, 4])  # 24

В функциональных языках это базовая конструкция, а в Python она применяется редко: явный цикл читается лучше, а для наиболее частых свёрток предусмотрены готовые sum, min, max, any, all и появившаяся в Python 3.8 math.prod, для которой math.prod([1, 2, 3, 4]) даёт те же 24. Встроенная sum для чисел с плавающей точкой с Python 3.12 выполняет компенсированное суммирование и точнее свёртки через сложение: sum([0.1] * 10) даёт 1.0, а functools.reduce(operator.add, [0.1] * 10) — 0.9999999999999999.

Другие средства functools

Остальные средства модуля относятся к классам, обёрткам и сортировке. total_ordering достраивает все операции сравнения класса по __eq__ и одному из методов __lt__, __le__, __gt__, __ge__; cached_property (Python 3.8) вычисляет атрибут при первом обращении и запоминает значение; partialmethod и singledispatchmethod являются вариантами partial и singledispatch для методов; cmp_to_key переводит функцию сравнения старого стиля в функцию-ключ.

Заключение

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

Таким образом, на практике потребуется следующее:

• Собственный декоратор всегда начинается с @functools.wraps(func) над внутренней функцией.
• Декоратор выполняется один раз, вместе с инструкцией def, а обёртка — при каждом вызове функции.
• Декоратор с аргументами представляет собой функцию, возвращающую декоратор; уровней вложенности становится три.
• Декоратор с необязательными настройками принимает их только по имени и проверяет, что первый аргумент является вызываемым объектом: звёздочка сама по себе не защищает от записи @deco(x).
• В цепочке декораторов ближайший к def применяется первым, а при вызове срабатывает последним.
• Прежде чем писать собственную реализацию, следует обратиться к functools: cache, lru_cache, partial, singledispatch и total_ordering покрывают большую часть потребностей.

Дополнительные материалы:

• Python Decorator Library
• PEP 443 – Single-dispatch generic functions
• PEP 318 – Decorators for Functions and Methods
• PEP 702 – Marking deprecations using the type system

Классы

Класс связывает данные с операциями, определёнными над ними, и вместо разрозненных переменных и обрабатывающих их функций получается один объект, отвечающий за своё состояние. От Java и C++ Python отличается тем, что не скрывает механику: ссылка на экземпляр передаётся методу явным первым аргументом self, а не появляется в теле сама собой.

ООП в Python не является обязательным. Модуль, составленный из десятка функций, представляет собой полноценную программу, и оборачивать её в класс только ради класса не требуется. Классы применяются тогда, когда у данных появляется состояние, которое необходимо поддерживать согласованным, или когда одну и ту же операцию требуется выполнять по-разному для объектов разного вида, обрабатываемых единым кодом.

Слайды к главе. Материал главы изложен также в лекции «Классы в Python» (классы и экземпляры, методы и свойства, наследование, магические методы, дескрипторы, метаклассы) с демонстрациями в интерактивной оболочке; слайды лекции доступны на сайте книги и в PDF.

Базовые понятия

Определение класса

Метод __init__ вызывается сразу после создания объекта и задаёт начальное состояние; всё, записанное в self, становится атрибутом конкретного экземпляра, которым и пользуются остальные методы.

class Counter:
    """I count. That is all."""

    def __init__(self, initial=0):  # начальное состояние
        self.value = initial        # запись атрибута

    def increment(self):
        self.value += 1

    def get(self):
        return self.value          # чтение атрибута

# Использование
c = Counter(42)
c.increment()
print(c.get())  # 43

Тело класса выполняется вместе с инструкцией class, обычно один раз, при импорте модуля: функции, объявленные в нём, становятся методами, а остальные присвоенные имена — атрибутами класса. Имена классов по PEP 8 записываются в стиле CapWords (Counter, MeasurementSeries).

Создание экземпляра: __new__ и __init__

Название «конструктор», закрепившееся за __init__, строго говоря неверно, поскольку объект к этому моменту уже создан. Вызов класса выполняется в два шага: метод __new__ получает те же аргументы, что и вызов, и создаёт объект, а затем __init__ заполняет заготовку, полученную от него. Разница проявляется при наследовании от неизменяемого типа наподобие int, float или tuple, у которого изменять уже нечего, и вся работа переносится в __new__.

class PositiveFloat(float):
    def __new__(cls, value):
        if value <= 0:
            raise ValueError("нужно > 0")
        return super().__new__(cls, value)

PositiveFloat(2.5) + 1   # 3.5
PositiveFloat(-1)        # ValueError: нужно > 0

Объект проверен при создании и участвует в арифметике как обычное число, но результат арифметики — уже обычный float, и проверка на него не действует: PositiveFloat(2.5) - 3 даёт -0.5. Аргументы передаются в super().__new__ только тогда, когда их потребляет базовый класс: float.__new__ принимает значение, а object.__new__ с лишними аргументами завершается TypeError.

Специфика Python

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

Модификаторов доступа наподобие private и protected в Python нет, вместо них действует соглашение об именовании.

• public_attribute составляет часть публичного интерфейса, и его использование допустимо;
• _internal_attribute является внутренним, извне к нему не обращаются;
• __private_attribute означает то же самое, но с дополнительной защитой от случайного переопределения, выполненного в подклассе.

Только за двойным подчёркиванием стоит механизм, встроенный в язык. Компилятор переписывает имя, помеченное таким образом, добавляя к нему имя класса, вследствие чего __private внутри класса Counter превращается в _Counter__private. Искажение лексическое: внутри тела класса self.__private и Counter.__private одинаково становятся _Counter__private. Механизм предназначен для предотвращения коллизий, а не для сокрытия данных, так что базовый класс и подкласс, объявив по атрибуту __cache, не столкнутся. Доступ к «приватному» атрибуту при этом сохраняется через полное имя. Имена с двумя подчёркиваниями с обеих сторон, такие как __init__, зарезервированы для специальных методов и не искажаются.

Атрибуты классов и экземпляров

Атрибуты в Python бывают двух видов, и путаница между ними приводит к трудноуловимым ошибкам.

Атрибуты экземпляра

Атрибут экземпляра появляется в результате присваивания, выполненного к self, и принадлежит только этому объекту. Создавать его не обязательно в __init__, поскольку присвоить атрибут можно и извне, уже созданному объекту.

class Noop:
    def __init__(self):
        self.some_attribute = 42

noop = Noop()
noop.other_attribute = 100500  # динамическое добавление

Эта свобода следует из того, что атрибуты хранятся в обычном словаре, и у неё есть оборотная сторона: опечатка в имени не вызовет ошибки. Строка noop.som_attribute = 0 без предупреждения создаст новый атрибут, а старый останется прежним.

Атрибуты класса

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

class Counter:
    all_counters = []  # атрибут класса

    def __init__(self, initial=0):
        Counter.all_counters.append(self)
        self.value = initial

# Также можно добавлять атрибуты после определения
Counter.some_other_attribute = 42

Ловушка та же, что с изменяемыми аргументами по умолчанию: список all_counters создаётся один раз, при выполнении инструкции class. Если бы он был задуман как список, заведённый у каждого счётчика отдельно, все экземпляры разделяли бы один. Здесь общий список необходим, однако при объявлении изменяемого атрибута класса проверяется, должен ли он быть общим. Кроме того, такой реестр удерживает созданные счётчики, и они не освобождаются никогда; реестр, не удерживающий объекты, строится на weakref.WeakSet.

При чтении c.value интерпретатор ищет имя сначала в словаре экземпляра, затем в словаре класса, затем в базовых классах в порядке разрешения методов; исключения из этой схемы составляют дескрипторы, рассматриваемые в конце главы. Присваивание через экземпляр, напротив, всегда пишет в словарь экземпляра: c.all_counters = [] создаст у c собственный атрибут, заслоняющий атрибут класса, а del c.all_counters снова откроет атрибут класса.

Словарь атрибутов

Все атрибуты экземпляра хранятся в обычном словаре __dict__, благодаря которому и работает динамическое добавление. В него можно заглянуть и просмотреть поля, имеющиеся у объекта.

noop = Noop()
noop.some_attribute = 42
print(noop.__dict__)  # {'some_attribute': 42}
print(vars(noop))     # тот же словарь

# Имя атрибута, вычисляемое во время выполнения
cfg = {"gain": 2.5, "threshold": 0.1}
for name, value in cfg.items():
    setattr(noop, name, value)
getattr(noop, "gain")          # 2.5
getattr(noop, "offset", 0.0)   # значение по умолчанию вместо AttributeError
hasattr(noop, "threshold")     # True

Встроенная vars() с аргументом возвращает __dict__ объекта, тот же словарь, а не копию, а без аргументов — словарь текущего локального пространства имён. Для имени атрибута, вычисляемого во время выполнения, применяются getattr, setattr, hasattr и delattr; прямая запись в __dict__ обходит свойства и __setattr__ и нужна редко, например внутри самого __setattr__. Параметры моделирования, прочитанные из файла настроек, переносятся в объект именно так, и имена при этом сверяются со списком допустимых: опечатка в файле создала бы лишний атрибут без сообщения об ошибке.

__slots__ для оптимизации

За гибкость приходится платить памятью: словарь атрибутов на объекте с двумя полями занимает больше самих полей. С Python 3.11 он создаётся лишь при первом обращении к __dict__, поэтому плата меньше, чем в прежних версиях, но при миллионах объектов, по одному на событие, зарегистрированное в эксперименте, она по-прежнему ощутима.

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

class Event:
    __slots__ = ("time", "energy")  # фиксирует набор атрибутов

    def __init__(self, time, energy):
        self.time = time
        self.energy = energy

e = Event(0.1, 511.0)
e.charge = -1  # AttributeError: 'Event' object has no attribute 'charge'

Замер модулем tracemalloc для 100 тысяч объектов с двумя полями, сложенных в список, вместе с 8 байтами ссылки из списка даёт в Python 3.12 88 байт на обычный объект, 152 байта после обращения к его __dict__ и 56 байт со __slots__; в 3.11 обычный объект занимает 96 байт. Скорость доступа при этом почти не меняется: в измерении из главы «Оптимизация средствами самого Python» разница оказалась в пределах шума. Взамен теряется динамика: атрибут, отсутствующий в списке, добавить не удастся, слабые ссылки работают, только если '__weakref__' указан в слотах, а подкласс без собственного __slots__ снова получает словарь. Начинать с __slots__ нецелесообразно; его добавляют тогда, когда профилировщик покажет, что память расходуется именно здесь. Для массовых числовых данных объекты заменяются массивами NumPy: событие из двух float64 в структурированном массиве занимает 16 байт вместе со значениями.

Методы

Методы и связывание

Метод представляет собой функцию, хранящуюся в атрибуте класса, и получить её можно двумя путями. Через класс получается обычная функция, требующая экземпляр, переданный явно. Через экземпляр получается связанный метод, в котором объект уже подставлен в self, и передавать его повторно не требуется.

class SomeClass:
    def do_something(self):
        print("Doing something.")

# Через класс — обычная функция (в Python 2 — несвязанный метод)
function = SomeClass.do_something
instance = SomeClass()
function(instance)  # экземпляр передаётся явно

# Через экземпляр — связанный метод
bound_method = instance.do_something
bound_method()  # self уже привязан
bound_method.__self__ is instance  # True

Связанный метод представляет собой полноценный объект: его помещают в переменную, передают в map или регистрируют как обработчик события, а ссылку на свой экземпляр (__self__) и функцию (__func__) он хранит в себе. Создаётся он при каждом обращении: instance.do_something is instance.do_something даёт False. В Python 2 обращение через класс давало особый тип, проверявший тип первого аргумента и не пропускавший посторонние объекты; в Python 3 это обычная функция. Само связывание выполняет протокол дескрипторов, рассматриваемый ниже.

Методы класса и статические методы

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

class Particle:
    def __init__(self, mass, v=0.0):
        self.mass, self.v = mass, v

    @classmethod
    def from_momentum(cls, mass, p):
        return cls(mass, v=p / mass)  # нерелятивистский случай, v << c

    @staticmethod
    def gamma(v, c=299_792_458.0):
        return 1 / (1 - (v / c) ** 2) ** 0.5

class Electron(Particle):
    pass

e = Electron.from_momentum(9.109e-31, 2.7e-24)
type(e).__name__  # 'Electron'

Декоратор classmethod делает метод, первым аргументом которого приходит класс, а не экземпляр. Типичное применение — альтернативные конструкторы, как dict.fromkeys и datetime.fromtimestamp: поскольку cls — фактический класс вызова, подкласс получает объект своего типа. Декоратор staticmethod убирает привязку совсем: метод получает только переданные аргументы и является функцией, помещённой в пространство имён класса, потому что относится к нему по смыслу. Альтернативные конструкторы удобны для чтения данных разных форматов: Spectrum.from_csv(path) и Spectrum.from_hdf5(path) разбирают каждый свой формат и вызывают общий __init__.

Свойства (Properties)

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

Это обеспечивает декоратор @property: метод, помещённый под ним, вызывается при чтении, метод под @имя.setter при записи, метод под @имя.deleter при удалении. Извне всё выглядит как обычное присваивание.

class BigDataModel:
    def __init__(self):
        self._params = []

    @property
    def params(self):
        return self._params

    @params.setter
    def params(self, new_params):
        if any(p <= 0 for p in new_params):
            raise ValueError("параметры должны быть положительны")
        self._params = new_params

    @params.deleter
    def params(self):
        del self._params

model = BigDataModel()
model.params = [0.1, 0.5, 0.4]
print(model.params)  # [0.1, 0.5, 0.4]

Присваивание model.params = [...] выглядит как запись в обычное поле, но проходит через проверку в сеттере. assert для такой проверки не годится: при запуске интерпретатора с ключом -O он удаляется вместе с проверкой. Свойство без сеттера доступно только для чтения, и присваивание завершается AttributeError; с Python 3.11 сообщение звучит как property 'params' of 'BigDataModel' object has no setter. Интерфейс не меняется, а поведение за ним может меняться произвольно. Производные величины — kT, плотность, давление — удобно оформлять свойствами: они вычисляются из состояния и всегда с ним согласованы. Значение, которое трудоёмко вычислять и которое после этого не меняется, вычисляется один раз декоратором functools.cached_property (Python 3.8): результат первого обращения сохраняется в словаре экземпляра. Внутренне свойства построены на дескрипторах, рассматриваемых ниже.

Классы данных

Значительная часть классов в расчётном коде — записи с именованными полями: результат измерения, параметры прогона, конфигурация детектора. Для них __init__, __repr__ и __eq__ пишутся однообразно, и эту работу выполняет декоратор dataclass (Python 3.7, PEP 557), строящий методы по аннотированным полям.

from dataclasses import dataclass, field

@dataclass(frozen=True, slots=True)
class Measurement:
    value: float
    error: float = 0.0
    unit: str = "м"

@dataclass
class Run:
    number: int
    events: list[int] = field(default_factory=list)

m = Measurement(9.81, 0.02)
m                             # Measurement(value=9.81, error=0.02, unit='м')
m == Measurement(9.81, 0.02)  # True
m.value = 10                  # FrozenInstanceError: cannot assign to field 'value'
Run(1).events is Run(2).events  # False

Изменяемое значение по умолчанию запрещено: объявление events: list = [] завершается ValueError с подсказкой применить default_factory. Аннотации при этом не проверяются: Measurement("9.81") создаётся без ошибки. От опечатки в имени поля защищает не всякий класс данных: лишний именованный аргумент при создании объекта даёт TypeError, но присваивание run.evnets = [1] у обычного @dataclass создаёт новый атрибут, и ошибку дают только slots=True или frozen=True. dataclass является декоратором класса, а не метаклассом: методы дописываются к готовому классу, а при slots=True декоратор возвращает новый класс со __slots__. Для неизменяемых записей без методов есть также typing.NamedTuple.

Наследование

Базовое наследование

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

class Counter:
    def __init__(self, initial=0):
        self.value = initial

class OtherCounter(Counter):
    def get(self):
        return self.value

oc = OtherCounter()  # вызывает Counter.__init__
print(oc.get())      # вызывает OtherCounter.get

Принадлежность объекта классу проверяется функцией isinstance(oc, Counter), учитывающей наследование, а не сравнением type(oc) == Counter, которое для экземпляра подкласса даёт False; issubclass(OtherCounter, Counter) проверяет отношение самих классов. Родителей, в отличие от многих языков, может быть несколько, и чем сложнее иерархия, тем труднее определить, чей метод, найденный по цепочке, будет вызван.

Переопределение методов и super()

Чаще подкласс не заменяет метод родителя целиком, а надстраивает над ним своё и передаёт управление выше, а ссылку на реализацию, унаследованную от родителя, предоставляет super().

class Counter:
    all_counters = []

    def __init__(self, initial=0):
        self.__class__.all_counters.append(self)
        self.value = initial

    def increment(self):
        self.value += 1

    def get(self):
        return self.value

class OtherCounter(Counter):
    def __init__(self, initial=0):
        self.initial = initial
        super().__init__(initial)  # вызов родительского __init__

Запись Counter.__init__(self, initial) вместо super() является распространённой ошибкой, и разница проявится при множественном наследовании. super() обращается не к родителю, а к следующему классу в порядке разрешения методов класса того объекта, у которого вызван метод (type(self).__mro__): у ThreadSafeCounter из раздела о примесях за примесью следует Counter, хотя примесь о нём не знает. Имя родителя, указанное явно, эту цепочку разрывает. Форма без аргументов работает благодаря неявной ячейке __class__, которую компилятор создаёт для функций, объявленных в теле класса; ручная запись super(self.__class__, self) при трёх уровнях наследования уходит в бесконечную рекурсию.

Множественное наследование

Порядок, в котором интерпретатор перебирает классы в поисках метода, называется MRO, то есть method resolution order, и вычисленный порядок доступен у любого класса.

class A:
    def f(self):
        print("A.f")

class B:
    def f(self):
        print("B.f")

class C(A, B):
    pass

print(C.mro())  # порядок разрешения методов
C().f()         # A.f (согласно MRO)

Здесь f находится в A, поскольку A стоит первым в списке родителей, перечисленных в скобках. Порядок, выстраиваемый здесь, вычисляет алгоритм C3, предложенный для языка Dylan и используемый в Python с версии 2.3, и он обеспечивает три гарантии. Подкласс всегда следует раньше своих родителей; порядок, в котором родители перечислены, сохраняется; каждый класс иерархии встречается в списке единожды. MRO вычисляется при создании класса, и если требования противоречат друг другу, Python откажется создавать класс.

class D(A, C):  # C — подкласс A, но указан после него
    pass
# TypeError: Cannot create a consistent method resolution
# order (MRO) for bases A, C

Классы-примеси

Примесью (mixin) называют класс, не предназначенный для самостоятельного использования и не описывающий сущность, а только добавляющий к чужому поведению одну черту, будь то блокировка, журналирование или кеширование. Ниже примесь оборачивает операции счётчика в блокировку, захватываемую на время вызова.

import threading

class ThreadSafeMixin:
    def __init__(self, *args, **kwargs):
        self._lock = threading.Lock()
        super().__init__(*args, **kwargs)

    def get_lock(self):
        return self._lock

    def increment(self):
        with self.get_lock():
            super().increment()

    def get(self):
        with self.get_lock():
            return super().get()

class ThreadSafeCounter(ThreadSafeMixin, Counter):
    pass

Всё это работает благодаря super() и порядку разрешения методов. Примесь стоит перед Counter в списке родителей, поэтому её increment перехватывает вызов первым, а super().increment(), расположенный внутри, передаётся дальше по цепочке, в настоящий счётчик. ThreadSafeMixin не наследуется от Counter и ничего о нём не знает: следующий класс в MRO определяется в момент, когда собирается ThreadSafeCounter. Замок при этом необходим и при GIL: self.value += 1 выполняется несколькими инструкциями байт-кода, и переключение потоков между ними возможно. Аналогичным образом устроены socketserver.ThreadingMixIn и значительная часть Django.

Композиция вместо наследования

Наследование выражает отношение «является»: электрон — частица, и любой код, работающий с частицей, обязан работать и с электроном (принцип подстановки Лисков). Если же объект лишь использует другой — детектор состоит из каналов, ускоритель — из магнитов и резонаторов, — это композиция: объект хранит другие объекты в атрибутах и поручает им работу.

class Channel:
    def __init__(self, number, gain):
        self.number, self.gain = number, gain

class Detector:
    def __init__(self, channels):
        self.channels = list(channels)  # содержит, а не является

    def total_gain(self):
        return sum(c.gain for c in self.channels)

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

Декораторы классов

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

import functools

def singleton(cls):
    instance = None

    @functools.wraps(cls)
    def inner(*args, **kwargs):
        nonlocal instance
        if instance is None:
            instance = cls(*args, **kwargs)
        return instance

    return inner

@singleton
class Noop:
    "I do nothing at all."

print(Noop() is Noop())  # True

Проверка Noop() is Noop() сравнивает два живых объекта. Распространённая запись id(Noop()) == id(Noop()) ничего не доказывает: первый временный объект уничтожается до создания второго, его адрес переиспользуется, и для обычного класса такое сравнение тоже даёт True. Цена синглтона в таком виде — класс подменён функцией, поэтому isinstance(x, Noop) и наследование от Noop больше не работают.

Декораторы классов появились в Python 2.6 и 3.0 (PEP 3129) и потеснили метаклассы: многое, ради чего раньше писался метакласс, теперь выполняется одной функцией. Наиболее известным примером является @dataclass, рассмотренный выше.

Магические методы

Магическими (или специальными) методами называют методы, чьи имена окружены двойными подчёркиваниями. Напрямую их не вызывают, поскольку за каждым стоит синтаксическая конструкция или встроенная функция. Определение нужного метода позволяет объекту вести себя как встроенный, то есть складываться, сравниваться, печататься, попадать в множество.

Неявный вызов ищет специальный метод у типа объекта, минуя словарь экземпляра: метод, присвоенный экземпляру (obj.__len__ = ...), на len(obj) не влияет.

Управление атрибутами

Первая группа перехватывает работу с атрибутами. __getattr__ вызывается только тогда, когда обычный поиск завершился AttributeError, и в нём подставляется значение вместо ошибки. __setattr__ и __delattr__, напротив, перехватывают любую запись и любое удаление.

class Settings:
    def __init__(self, **values):
        object.__setattr__(self, "_values", values)

    def __getattr__(self, name):
        # Вызывается, если обычный поиск не нашёл атрибут
        values = self.__dict__.get("_values", {})
        if name in values:
            return values[name]
        raise AttributeError(name)

    def __setattr__(self, name, value):
        # Вызывается при записи любого атрибута
        raise AttributeError("настройки только для чтения")

    def __delattr__(self, name):
        # Вызывается при удалении любого атрибута
        raise AttributeError("настройки только для чтения")

cfg = Settings(gain=2.5, threshold=0.1)
print(cfg.gain)         # 2.5
hasattr(cfg, "offset")  # False
cfg.gain = 3            # AttributeError: настройки только для чтения

Для неизвестного имени __getattr__ обязан бросать AttributeError, а не возвращать значение и не бросать другое исключение: на этом основаны hasattr, getattr со значением по умолчанию, копирование copy и сериализация pickle. Поскольку __getattr__ вызывается и тогда, когда AttributeError возникла внутри геттера свойства, он может маскировать ошибку в свойстве. Запись внутри __setattr__ выполняется через object.__setattr__ или super().__setattr__, иначе self.name = value снова вызовет метод и приведёт к бесконечной рекурсии; по той же причине __getattr__ читает служебное поле через self.__dict__: у объекта, созданного копированием без вызова __init__, этого поля ещё нет. Переопределять __getattribute__, перехватывающий доступ ко всем атрибутам, а не только к отсутствующим, не рекомендуется. Готовый объект с доступом к значениям через точку — types.SimpleNamespace.

Операторы сравнения

Вторая группа отвечает за сравнение, и методов в ней шесть, но записывать все шесть не требуется: декоратор @functools.total_ordering достроит остальные по __eq__ и любому одному из методов, задающих упорядочивание.

import functools

@functools.total_ordering
class Counter:
    def __init__(self, value):
        self.value = value

    def __eq__(self, other):
        if not isinstance(other, Counter):
            return NotImplemented
        return self.value == other.value

    def __lt__(self, other):
        if not isinstance(other, Counter):
            return NotImplemented
        return self.value < other.value

c1, c2 = Counter(1), Counter(2)
print(c1 < c2)   # True
print(c1 >= c2)  # False (достроено из __lt__ и __eq__)
print(c1 == 1)   # False: сравнение с объектом другого типа

Для объекта чужого типа методы возвращают NotImplemented, и интерпретатор пробует отражённую операцию второго операнда, а при неудаче сравнивает объекты на равенство по идентичности; без этой проверки Counter(1) == 1 завершилось бы AttributeError. __ne__ по умолчанию обращает результат __eq__, а при отсутствии __gt__ интерпретатор пробует отражённое c2 < c1, поэтому без total_ordering не выводятся только <= и >=.

Определение __eq__ отключает хеширование: интерпретатор присваивает __hash__ = None, и объект не попадёт ни в множество, ни в ключи словаря. Причина та же, что у изменяемых коллекций: равные объекты обязаны иметь равные хеши, а хеш по умолчанию основан на идентичности объекта и с новым равенством не согласован. Если объект должен оставаться хешируемым, __hash__ определяется явно и вычисляется из тех же полей, что участвуют в сравнении, причём только для объектов, которые после создания не меняются: объект, изменившийся после помещения в множество, поиск в нём не находит.

Строковое представление

Третья группа отвечает за текстовое представление. __repr__ предназначен для программиста: он должен быть однозначным и в идеале выглядеть как выражение, воссоздающее объект. __str__ предназначен для человека, просматривающего вывод программы. Если __str__ не определён, Python использует __repr__, поэтому начинают именно с него.

class Counter:
    def __init__(self, initial=0):
        self.value = initial

    def __repr__(self):
        return f"Counter({self.value})"

    def __str__(self):
        return f"Counted to {self.value}"

    def __format__(self, format_spec):
        return self.value.__format__(format_spec)

c = Counter(42)
print(repr(c))           # Counter(42)
print(str(c))            # Counted to 42
print(f"{c:b}")          # 101010 (бинарное представление)

Третий метод, __format__, отвечает за подстановку в f-строку со спецификатором, а здесь он передаёт полученный спецификатор дальше в целое число, поэтому {c:b} печатает значение счётчика в двоичном виде.

__repr__ имеет смысл определять у любого класса, существующего дольше пары строк, иначе при отладке объекты печатаются как <__main__.Counter object at 0x7f3a…>.

Арифметические операторы и NotImplemented

Арифметические операторы вызывают методы __add__, __sub__, __mul__, __truediv__, __pow__ и другие. Класс величины с погрешностью ниже складывает погрешности независимых величин в квадратуре и масштабирует погрешность при умножении на точное число.

import math

class Measured:
    def __init__(self, value, error):
        self.value, self.error = value, error

    def __repr__(self):
        return f"Measured({self.value!r}, {self.error!r})"

    def __add__(self, other):
        if not isinstance(other, Measured):
            return NotImplemented
        error = math.hypot(self.error, other.error)
        return Measured(self.value + other.value, error)

    def __mul__(self, k):
        if not isinstance(k, (int, float)):
            return NotImplemented
        return Measured(self.value * k, abs(k) * self.error)

    __rmul__ = __mul__

a, b = Measured(1.5, 0.3), Measured(2.5, 0.4)
a + b  # Measured(4.0, 0.5)
2 * a  # Measured(3.0, 0.6): отражённый __rmul__
a + 1  # TypeError: unsupported operand type(s) for +: 'Measured' and 'int'

Если левый операнд не умеет работать с правым, метод возвращает специальное значение NotImplemented, и интерпретатор пробует отражённый метод правого операнда: для a + b это b.__radd__(a). Если и он вернул NotImplemented, возникает TypeError. Поэтому для неподходящего типа возвращается NotImplemented, а не бросается исключение: другой тип сохраняет возможность обработать операцию. Отражённый метод вызывается, только если типы операндов различны; если правый операнд — экземпляр подкласса и переопределяет отражённый метод, этот метод вызывается первым. __rmul__ нужен, чтобы работало 2 * a: умножение int на Measured не определено. Для составного присваивания a += b ищется __iadd__, а без него выполняется __add__ с созданием нового объекта; унарные операции — __neg__, __pos__, __abs__.

Зависимость величин класс не учитывает: a + a даёт погрешность σ√2, хотя верно 2σ, как у 2 * a. Учёт корреляций и производных для нелинейных функций реализован в пакете uncertainties.

Протоколы коллекций

Коллекции определяются протоколами — наборами методов. Спектр ниже определяет два метода и уже ведёт себя как последовательность.

class Spectrum:
    def __init__(self, counts):
        self._counts = list(counts)

    def __len__(self):
        return len(self._counts)

    def __getitem__(self, i):
        if isinstance(i, slice):
            return type(self)(self._counts[i])
        return self._counts[i]

s = Spectrum([3, 5, 8, 2])
len(s), s[2]           # (4, 8)
list(s), 8 in s        # ([3, 5, 8, 2], True)
list(reversed(s))      # [2, 8, 5, 3]
type(s[1:3]).__name__  # 'Spectrum'

__len__ даёт функцию len и, при отсутствии __bool__, истинность: пустая коллекция ложна. __getitem__ даёт индексирование, а получив объект slice, — срезы; здесь срез возвращает новый спектр, а не список. Двух методов достаточно, чтобы объект перебирался в цикле for (интерпретатор вызывает __getitem__ с индексами 0, 1, 2 и так далее до IndexError), проверялся оператором in и разворачивался функцией reversed. Современный протокол перебора — метод __iter__, возвращающий итератор (глава «Итераторы, генераторы и корутины»); __contains__ ускоряет проверку in, если ответ получается без перебора, а __setitem__ и __delitem__ дают запись и удаление элементов. Наследование от collections.abc.Sequence добавит index, count и __reversed__ по тем же двум методам и сделает объект последовательностью для isinstance; без него isinstance(s, Sequence) даёт False.

Другие полезные магические методы

__call__ делает экземпляр вызываемым: g(x) выполняет g.__call__(x).

import math

class Gaussian:
    def __init__(self, mu, sigma):
        self.mu, self.sigma = mu, sigma

    def __call__(self, x):
        z = (x - self.mu) / self.sigma
        return math.exp(-z * z / 2)

g = Gaussian(0.0, 2.0)
g(2.0)       # 0.6065306597126334
callable(g)  # True

Такой объект подходит везде, где ожидается функция, — в интеграторе scipy.integrate.quad, оптимизаторе или в sorted как ключ, — и, в отличие от замыкания, хранит параметры в именованных атрибутах, имеет repr и может иметь другие методы. На __call__ основаны и декораторы, реализованные классами. __bool__ задаёт, что объект означает в условии if; без него Python обращается к __len__, и объект нулевой длины оказывается ложным, а объект без обоих методов истинен всегда. __hash__ определяет, как объект попадает в множества и словари; хеш по умолчанию выводится из идентичности объекта, и писать его вручную для этого не требуется.

Дескрипторы

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

Базовый дескриптор

Дескриптор представляет собой объект, класс которого определяет хотя бы один из методов __get__, __set__ или __delete__. Помещённый в атрибут класса, он перехватывает обращение к этому атрибуту у всех экземпляров: чтение obj.x вызывает __get__(obj, type(obj)), обращение через класс — __get__(None, cls), запись — __set__, удаление — __delete__. Метод __set_name__ (Python 3.6, PEP 487) вызывается при создании класса и сообщает дескриптору имя, под которым он записан.

class Positive:
    def __set_name__(self, owner, name):
        self.public, self.name = name, "_" + name

    def __get__(self, obj, objtype=None):
        if obj is None:
            return self
        return getattr(obj, self.name)

    def __set__(self, obj, value):
        if value <= 0:
            raise ValueError(f"{self.public}: ожидается > 0")
        setattr(obj, self.name, value)

class Particle:
    mass = Positive()
    lifetime = Positive()

    def __init__(self, mass, lifetime):
        self.mass, self.lifetime = mass, lifetime

muon = Particle(0.1057, 2.2e-6)
muon.lifetime = -1   # ValueError: lifetime: ожидается > 0
vars(muon)           # {'_mass': 0.1057, '_lifetime': 2.2e-06}

Проверка написана один раз, защищённых ею полей два, и добавление третьего требует одной строки. Обращение через класс, Particle.mass, передаёт obj = None, и по соглашению возвращается сам дескриптор.

Дескрипторы данных определяют __set__ или __delete__, дескрипторы не данных — только __get__. От этого зависит порядок поиска при чтении атрибута:

1. дескриптор данных в классе или его базовых классах;
2. запись в словаре экземпляра;
3. дескриптор не данных или обычный атрибут класса;
4. метод __getattr__, если он определён, иначе AttributeError.

Поэтому дескриптор данных, например свойство, нельзя заслонить записью в словарь экземпляра, а дескриптор не данных — можно. Через дескрипторы в Python реализовано почти всё, связанное с атрибутами: и @property, и @staticmethod, и @classmethod, и сама привязка методов к экземпляру. Обычная функция — дескриптор не данных, её __get__ возвращает связанный метод, поэтому функция, хранящаяся в классе, при обращении через экземпляр оказывается связанным методом, а атрибут экземпляра с тем же именем её заслоняет. Встроенные функции вроде len дескрипторами не являются: после A.length = len вызов A().length() метода не даёт.

Хранение данных в дескрипторах

Хранить значение в самом дескрипторе нельзя: он один на весь класс, а экземпляров много, и значения, записанные ими, затирали бы друг друга. Дескриптор Positive хранит значение в атрибуте экземпляра с подчёркиванием; другой вариант — запись в словаре экземпляра под меткой поля.

class Proxy:
    def __init__(self, label):
        self.label = label

    def __get__(self, instance, owner):
        if instance is None:
            return self
        try:
            return instance.__dict__[self.label]
        except KeyError:
            raise AttributeError(self.label) from None

    def __set__(self, instance, value):
        instance.__dict__[self.label] = value

    def __delete__(self, instance):
        del instance.__dict__[self.label]

class Something:
    attr = Proxy("attr")

some = Something()
some.attr = 42
print(some.attr)  # 42

У каждого экземпляра значение своё, и существует оно столько же, сколько сам экземпляр. Отсутствующее значение даёт AttributeError, а не KeyError, иначе hasattr и getattr со значением по умолчанию завершались бы ошибкой. Вариант со словарём «экземпляр → значение», заведённым внутри дескриптора, хуже по двум причинам: он требует хешируемых объектов и удерживает их, не позволяя сборщику мусора удалить, если не применить weakref.WeakKeyDictionary. Ключ id(instance) вместо самого экземпляра не помогает: после удаления объекта тот же адрес получает новый объект вместе с чужим значением.

Имя поля приходится дублировать в Proxy("attr"); начиная с Python 3.6 от этого избавляет метод __set_name__, как в Positive.

Встроенные дескрипторы

Три реализации ниже сокращены, но передают устройство, заложенное в интерпретатор.

# @property реализован через дескрипторы
class property:
    def __init__(self, fget=None, fset=None, fdel=None):
        self.fget, self.fset, self.fdel = fget, fset, fdel

    def __get__(self, instance, owner):
        if instance is None:
            return self
        if self.fget is None:
            raise AttributeError("свойство без геттера")
        return self.fget(instance)

    def __set__(self, instance, value):
        if self.fset is None:
            raise AttributeError("свойство без сеттера")
        self.fset(instance, value)

    def __delete__(self, instance):
        if self.fdel is None:
            raise AttributeError("свойство без делитера")
        self.fdel(instance)

# @staticmethod и @classmethod тоже используют дескрипторы
class staticmethod:
    def __init__(self, method):
        self.__method = method

    def __get__(self, instance, owner):
        return self.__method

class classmethod:
    def __init__(self, method):
        self.__method = method

    def __get__(self, instance, owner):
        if owner is None:
            owner = type(instance)
        return self.__method.__get__(owner, type(owner))

property — дескриптор данных даже без сеттера: запись в свойство только для чтения завершается AttributeError, а не создаёт атрибут экземпляра. Вся разница между @staticmethod и @classmethod заключается в их __get__. Статический метод возвращает исходную функцию без привязки, поэтому self в нём отсутствует. Метод класса привязывает функцию к классу, и первым аргументом приходит сам класс. Аналогично, только к экземпляру, привязываются обычные методы.

Метаклассы

Поскольку класс является объектом, у него также есть тип. Типом обычного класса служит type, а метаклассом называют класс, экземплярами которого оказываются другие классы; обычно это подкласс type. Сам type — метакласс по умолчанию, и type(type) — снова type. Если обычный класс описывает, как устроены его объекты, то метакласс описывает, как устроены сами классы.

Требуются они редко: почти всё, ради чего раньше писались метаклассы, сегодня выполняется декоратором, применённым к классу, или методом __init_subclass__. На метаклассах построены abc.ABCMeta, enum.EnumType (до Python 3.11 — EnumMeta), модели Django и pydantic, где поля, объявленные в классе, описываются декларативно.

Создание класса

Инструкция class выполняется в несколько шагов, и каждый даёт точку вмешательства:

1. выбор метакласса — наиболее производного из указанного аргументом metaclass и метаклассов базовых классов, при их отсутствии — type;
2. вызов метода метакласса __prepare__(name, bases), возвращающего словарь для пространства имён тела;
3. выполнение тела класса в этом словаре;
4. вызов метакласса metaclass(name, bases, namespace): его __new__ создаёт объект класса, __init__ донастраивает;
5. внутри type.__new__ — вызов __set_name__ у дескрипторов и __init_subclass__ у ближайшего базового класса;
6. применение декораторов класса к готовому классу и связывание имени.

Создание классов через type()

Без инструкции class тот же класс создаётся вызовом type с тремя аргументами: именем, родителями и словарём атрибутов.

# Эквивалентно class Something: attr = 42
name, bases, attrs = "Something", (), {"attr": 42}
Something = type(name, bases, attrs)

some = Something()
print(some.attr)  # 42

Так классы строят программно, например по описанию таблицы или конфигурации. Эквивалентность неполная: методы, переданные в type() извне, не могут вызывать super() без аргументов, поскольку ячейку __class__ компилятор создаёт только для функций, объявленных в теле класса.

__init_subclass__

Метод __init_subclass__ (Python 3.6, PEP 487) вызывается у базового класса при создании каждого подкласса и получает именованные аргументы из строки объявления. Так строится реестр подклассов, позволяющий выбрать реализацию по строке из файла конфигурации, проверяются обязательные атрибуты, задаются настройки, — без метакласса.

class Reader:
    registry = {}

    def __init_subclass__(cls, /, name=None, **kwargs):
        super().__init_subclass__(**kwargs)
        if name is not None:
            Reader.registry[name] = cls

class CsvReader(Reader, name="csv"): ...
class Hdf5Reader(Reader, name="hdf5"): ...
class GzipCsvReader(CsvReader): ...  # без имени — в реестр не попадает

sorted(Reader.registry)            # ['csv', 'hdf5']
reader = Reader.registry["hdf5"]()

Значение None по умолчанию позволяет объявлять промежуточные подклассы без имени: если бы параметр name был обязательным, объявление GzipCsvReader завершилось бы TypeError.

Базовый метакласс

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

class Meta(type):
    def __new__(mcls, name, bases, ns):
        print("создаётся", name, list(ns))
        return super().__new__(mcls, name, bases, ns)

class Detector(metaclass=Meta):
    gain = 2.5
# создаётся Detector ['__module__', '__qualname__', 'gain']

class Tracker(Detector):
    pass
# создаётся Tracker ['__module__', '__qualname__']

Метакласс наследуется: подкласс Tracker создан тем же Meta, хотя не указывает его. Если у базовых классов разные метаклассы, не связанные наследованием, возникает TypeError: metaclass conflict. В Python 3.13 в пространстве имён класса появились также служебные __firstlineno__ и __static_attributes__, и печать в примере длиннее.

Второй метод, __prepare__, выбирает, в чём накапливать тело класса, пока оно выполняется. С версии 3.6 (PEP 520) обычный словарь и без него сохраняет порядок объявления атрибутов, поэтому собственное отображение нужно не ради порядка, а для контроля присваиваний: так enum запрещает повторное имя члена перечисления, и объявление RED дважды завершается TypeError: 'RED' already defined as 1. После создания класса пространство имён копируется в обычный словарь, и возможности собственного отображения доступны лишь внутри __new__.

Модуль abc для абстрактных базовых классов

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

from abc import ABC, abstractmethod

class Integrator(ABC):
    @abstractmethod
    def step(self, f, t, y, h): ...

    def run(self, f, y0, t0, t1, n):
        h, t, y = (t1 - t0) / n, t0, y0
        for _ in range(n):
            y, t = self.step(f, t, y, h), t + h
        return y

class Euler(Integrator):
    def step(self, f, t, y, h):
        return y + h * f(t, y)

Integrator()                                       # TypeError
Euler().run(lambda t, y: -y, 1.0, 0.0, 1.0, 1000)  # 0.36769542477096373

Пока хотя бы один абстрактный метод не реализован, экземпляр не создаётся. Ошибка TypeError возникает при создании экземпляра, а не при первом обращении к недостающему методу, тогда как неполный подкласс объявляется без ошибки: так допускаются промежуточные абстрактные классы, а нереализованные абстрактные методы наследуются абстрактными. Текст ошибки зависит от версии; в Python 3.12 он звучит как Can't instantiate abstract class Integrator without an implementation for abstract method 'step'. Схема Эйлера на отрезке [0, 1] за 1000 шагов даёт 0,36770 при точном значении exp(−1) ≈ 0,36788, как и ожидается для схемы первого порядка; схемы Рунге — Кутты и Верле (для уравнений движения q'' = a(q)) реализуют тот же метод step, и сравнение их точности на одной задаче сводится к замене объекта-интегратора.

Отдельной конструкции interface, как в Java, в Python нет: интерфейсы описываются обычными классами с метаклассом abc.ABCMeta, проще всего — наследованием от готового abc.ABC. Метод register объявляет виртуальный подкласс для isinstance без проверки методов. Структурную проверку без наследования даёт typing.Protocol (Python 3.8, PEP 544): анализатор типов принимает любой объект с нужными методами.

Модуль collections.abc

Абстрактные классы для самих коллекций уже написаны и находятся в collections.abc, и это те же Container, Iterable, Sequence и Mapping, рассмотренные в главе «Коллекции». Наследование даёт две выгоды: интерпретатор сначала проверит, что реализовано всё обязательное, а затем сам добавит остальное. Реализация у MutableMapping пяти методов даёт готовые get, pop, popitem, setdefault, update, clear, items, keys, values, проверку in и сравнение.

from collections import deque
from collections.abc import MutableMapping

class MemorizingDict(MutableMapping):
    def __init__(self, *args, **kwargs):
        self._data = {}
        self._history = deque(maxlen=10)
        self.update(*args, **kwargs)  # через __setitem__, с историей

    def __getitem__(self, key):
        return self._data[key]

    def __setitem__(self, key, value):
        self._history.append(key)
        self._data[key] = value

    def __delitem__(self, key):
        del self._data[key]

    def __iter__(self):
        return iter(self._data)

    def __len__(self):
        return len(self._data)

    def get_history(self):
        return self._history

Написано пять обязательных методов и один собственный, а в результате получается полноценный словарь, запоминающий десять последних записанных ключей, включая ключи из конструктора: update из MutableMapping записывает их через __setitem__. Он пройдёт isinstance(d, MutableMapping) и будет принят функциями, работающими с любым отображением, например str.format_map; json.dumps принимает только dict, и для него выполняется dict(d).

Наследоваться ради той же задачи напрямую от dict ненадёжно: методы dict, реализованные на C, не вызывают переопределённый __setitem__, и конструктор, update и setdefault записывают ключи в обход истории. Для собственных отображений поэтому берут collections.abc.MutableMapping или collections.UserDict.

Заключение

Большая часть этого инструментария в повседневной практике не потребуется: собственный метакласс за студенческую практику, скорее всего, не понадобится ни разу, собственный дескриптор — в лучшем случае однажды. Рассматриваются они потому, что почти всё, кажущееся в Python магией, оказывается одним из этих механизмов.

В повседневной работе достаточно немногого:

• Класс необходим там, где есть состояние, которое требуется поддерживать согласованным. Если состояния нет, достаточно функции.
• Для записи с именованными полями достаточно @dataclass.
• Атрибут остаётся атрибутом; свойство добавляется тогда, когда за ним потребовалась логика.
• __repr__ определяется сразу, а методы сравнения и арифметики возвращают NotImplemented для чужих типов.
• В переопределённых методах родитель вызывается через super(), а не по имени класса.
• Прежде чем строить иерархию наследования, целесообразно проверить, не решается ли задача композицией: объект, содержащий другой объект, почти всегда проще объекта, унаследованного от него.
• Реестр подклассов строится через __init_subclass__; метакласс нужен лишь для изменения самого создания класса.

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

Роль алгоритмов в работе физика

Устройство Python было рассмотрено в предыдущем разделе, однако за ним стоит фундамент, переживающий и смену языка, и смену моды, — базовые знания computer science.

Алгоритмическая грамотность представляет собой умение заранее оценить, выполним ли расчёт за приемлемое время. Миллион событий детектора, обрабатываемый алгоритмом за \(O(n^2)\), приводит к триллиону операций, и NumPy, написанный на C, уменьшает лишь константу, но не порядок роста: расчёт сократится с часов до десятков минут, тогда как алгоритм \(O(n \log n)\) выполнит ту же работу меньше чем за секунду. Удачно выбранная структура данных сокращает время счёта на порядки, причём чаще, чем низкоуровневая оптимизация.

Слайды к главе. Материал первых трёх глав раздела изложен также в лекции «Алгоритмы и сложность» (алгоритм и O-нотация, время и память, память и массивы, списки и очереди, стек вызовов и рекурсия, сортировки) с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Слайды к главе. Материал глав о хеш-функциях, деревьях и графах изложен также в лекции «Хеши, деревья и графы» (хеш-таблицы и хеш-функции, деревья и деревья поиска, кучи, графы, кратчайшие пути и остов) с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

В настоящем разделе рассматриваются:

• Введение в алгоритмы, где вводится понятие алгоритма и разбирается оценка сложности, не привязанная к конкретной машине;
• Основные структуры данных, где разобраны массивы, списки, стеки, очереди и деки и показано, как они представлены в Python;
• Рекурсия и сортировки, где разобраны сортировка слиянием, быстрая сортировка и сортировка подсчётом;
• Хеш-функции, объясняющие, почему словарь ищет в среднем за \(O(1)\) и как устроены хеш-таблицы;
• Деревья, иерархические структуры, дополненные деревьями поиска и кучами;
• Графы, их представления, обходы и классические задачи, решаемые обходом.

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

Введение в алгоритмы

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

Слайды к главе. Свойства алгоритма и проблема останова, линейный и бинарный поиск, O-нотация и оценка сложности по виду кода и измерением изложены также в первой части лекции «Алгоритмы и сложность» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Линейный поиск

Дан массив целых чисел длины \(N\). Требуется найти в нём заданное число \(x\) и вернуть его индекс. Если \(x\) в массиве не встречается, необходимо вернуть -1.

def find_element(numbers, x):
    for i in range(len(numbers)):
        if numbers[i] == x:
            return i
    return -1

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

Вычислительная сложность представляет собой количество элементарных операций, совершаемых алгоритмом. Под входными данными понимается всё, поданное алгоритму на вход; в рассматриваемой задаче это массив numbers и число x, а размер входа примерно равен N. Линейная зависимость описывается формулой \(y = kx+b\).

Бинарный поиск

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

Допустим, что поиск ведётся по словарю из 100 страниц. Объём рассматриваемой части книги будет каждый раз уменьшаться вдвое до тех пор, пока не останется всего одна страница. Делить словарь из 100 страниц пополам можно не более 7 раз, а значит, для нахождения нужного слова достаточно просмотреть не более 7 страниц.

Этот алгоритм называется бинарным поиском, а также: двоичный поиск, метод деления пополам, дихотомия. Время его работы логарифмически зависит от размера входных данных.

def binary_search(arr, x):
    mid, low, high = 0, 0, len(arr) - 1

    while low <= high:
        mid = (high + low) // 2

        if arr[mid] < x:
            low = mid + 1
        elif arr[mid] > x:
            high = mid - 1
        else:
            return mid

    return -1

Бинарный поиск в сравнении с линейным

Запустим оба поиска на одних и тех же данных и рассмотрим, как меняется измеренное время работы с ростом массива.

Будем искать элемент, стоящий в самом конце, что даёт худший случай для линейного поиска:

При увеличении массива в 10 раз линейный поиск замедляется также примерно вдесятеро: 11 мкс, 122 мкс, 1,3 мс, 12 мс. Бинарный же поиск за пять порядков роста замедлился всего впятеро, с 0,14 до 0,69 мкс.

Именно так выглядит разница между \(O(n)\) и \(O(\log n)\) на практике. На миллионе элементов бинарный поиск быстрее линейного почти в восемнадцать тысяч раз, и чем больше накопленных данных, тем этот разрыв шире. На машине стенда лекции (CPython 3.12.3, ARM64) те же функции на миллионе элементов работают 12,2 мс и 0,72 мкс, отношение составляет около 17 тысяч. На той же машине функция bisect.bisect_left из стандартной библиотеки, написанная на C, выполняет бинарный поиск ещё в 9 раз быстрее функции на Python: при одинаковой сложности константа реализации остаётся существенной.

Измерение может быть воспроизведено самостоятельно:

from timeit import timeit

n = 1_000_000
setup = f"from __main__ import find_element, binary_search; arr = list(range({n})); x = {n} - 1"
print(timeit("find_element(arr, x)", setup=setup, number=1000) / 1000)
print(timeit("binary_search(arr, x)", setup=setup, number=1000) / 1000)

Сложность алгоритма. O-нотация

Для того чтобы говорить о скорости алгоритма, не привязываясь к конкретной машине, была введена O-нотация — запись, показывающая, как растёт число операций с ростом входных данных. Формально \(f(n) = O(g(n))\), если существуют постоянная \(c > 0\) и порог \(n_0\), начиная с которого \(f(n) \le c \cdot g(n)\). Константы и коэффициенты в оценке не учитываются: если алгоритм совершает \(5\cdot n+3\) операций, его сложность равна \(O(n)\), поскольку \(5n + 3 \le 6n\) при \(n \ge 3\). Отброшенные константы, однако, определяют применимость алгоритма при конкретных размерах данных: асимптотически лучший алгоритм может проигрывать на практике, если его константа велика, а выигрыш от асимптотики растёт медленно.

Кроме линейной и логарифмической, при оценке времени работы алгоритмов часто встречаются следующие зависимости:

• Квадратичная зависимость \(O(n^2)\).
• Кубическая зависимость \(O(n^3)\).
• Экспоненциальная зависимость \(O(2^n)\).
• Константная зависимость \(O(1)\). Встречаются и случаи, когда время работы алгоритма не зависит от размера входных данных, а число выполняемых операций остаётся постоянным.

Слайды к главе. Оценка времени исполнения, пространственная сложность, краевые случаи, задача о частом символе и поиск простых чисел изложены также во второй части лекции «Алгоритмы и сложность»; слайды лекции доступны на сайте книги и в PDF.

Оценка времени исполнения

Тактовая частота современного процессора составляет около 2,5 ГГц: за секунду проходит 2,5 миллиарда тактов.

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

Предположим, что обработка каждой итерации цикла занимает один такт процессора. Возьмём \(10^9\) итераций, тогда:

$$ t = \frac{10^9 [\text{итер}] \cdot 1 [\frac{\text{такт}}{\text{итер}}]}{2{,}5 \cdot 10^9 [\frac{\text{такт}}{\text{с}}]} = 0{,}4 [\text{с}] $$

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

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

Чтобы оценить, во сколько раз ошибается такая оценка, измерим, сколько секунд займёт пустой цикл, выполненный миллиард раз.

# Python
import time

time_start = time.time()
i = 0
while i < 1000000000:
    # Do nothing
    i += 1

time_finish = time.time()
time_span = time_finish - time_start
print(time_span, 'seconds')

27.69246792793274 seconds

// CPP
#include <chrono>
#include <iostream>

int main() {
    using namespace std::chrono;
    auto time_start = high_resolution_clock::now();
    int i = 0;
    while (i < 1000000000) {
        // Do nothing
        ++i;
    }
    auto time_finish = high_resolution_clock::now();
    auto time_span = duration_cast<duration<double>>(time_finish - time_start);

    std::cout << time_span.count() << " seconds\n";
  return 0;
}

Каждая итерация цикла состоит из трёх действий: прибавить единицу, проверить условие и переместиться обратно к началу цикла, — и три миллиарда команд при одной команде за такт заняли бы около 1,2 с. Сборка без оптимизации (c++ -O0 loop.cpp) выполняется быстрее: на процессоре ARM64 — за 0,2–0,5 с в зависимости от компилятора, поскольку современное ядро выполняет несколько команд за такт и работает на частоте выше 2,5 ГГц. С -O2 компилятор обнаруживает, что i далее нигде не используется, удаляет цикл целиком и печатает почти ноль; чтобы этого не происходило, счётчик объявляют volatile. Одного использования результата для этого недостаточно: если конечное значение счётчика вычислимо заранее, как здесь \(i = 10^9\), компилятор подставляет его без выполнения цикла. Это классическая ловушка микробенчмарков на компилируемых языках. Аналогичная программа на Python выполняется около 28 секунд: вывод выше получен на CPython 3.11 с процессором ARM64, а на машине стенда лекции (CPython 3.12.3, ARM64) замер на \(10^7\) итерациях даёт в пересчёте те же 28 с. Это примерно в 60–120 раз медленнее сборки без оптимизации на той же машине, в зависимости от компилятора. Так происходит, поскольку код, написанный на языках низкого уровня, почти один к одному транслируется в инструкции процессору, а каждая итерация цикла на Python выполняется сотнями машинных инструкций интерпретатора.

Пространственная сложность алгоритма

Вычислительная (или временнáя) сложность показывает, насколько экономно алгоритм расходует процессорное время. Второй характеристикой является объём оперативной памяти. Программы, не помещающиеся в неё, зависают и мешают работе остальных, а часто и не доводят вычисление до конца.

Если программам не хватает оперативной памяти, операционная система использует файл подкачки, или swap-раздел (от англ. swap, «подкачивать»), расположенный во внешней памяти (на жёстком диске или на SSD-диске): она переносит редко используемые страницы памяти из небольшой, но быстрой оперативной памяти на большой, но медленный диск и возвращает их обратно по мере обращения к ним. Это очень медленный процесс. Из-за него программы, вышедшие за пределы оперативной памяти, простаивают в ожидании диска и замедляются на порядки, даже если у них небольшая временна́я сложность. Более того, они могут вытеснять из памяти другие программы, замедляющиеся следом. Если запущенные на компьютере программы заняли не только всю оперативную память, но и файл подкачки, то какая-то из программ завершится аварийно.

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

Взаимосвязь пространственной и временной сложности алгоритма

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

Тестирование программы

Код, разделённый на функции, удобно тестировать: для каждой выделенной функции пишутся юнит-тесты.

Необходимо продумать краевые случаи — входные данные, на которых программы отказывают чаще всего:

Задача

Дана строка (UTF-8). Требуется найти самый часто встречающийся в ней символ.

Решение 1

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

s = 'ababa'
ans = ''
anscnt = 0
for i in range(len(s)):
    nowcnt = 0
    for j in range(len(s)):
        if s[i] == s[j]:
            nowcnt += 1
    if nowcnt > anscnt:
        ans = s[i]
        anscnt = nowcnt
print(ans)

a

Решение 2

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

s = 'ababa'
ans = ''
anscnt = 0
for now in sorted(set(s)):
    nowcnt = 0
    for j in range(len(s)):
        if now == s[j]:
            nowcnt += 1
    if nowcnt > anscnt:
        ans = now
        anscnt = nowcnt
print(ans)

a

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

Решение 3

Заведём словарь, в котором ключом служит символ, а значением — число его вхождений. Если символ встретился впервые, для него создаётся элемент словаря со значением ноль, после чего к созданному элементу прибавляется единица.

s = 'ababa'
ans = ''
anscnt = 0
symcnt = {}
for now in s:
    if now not in symcnt:
        symcnt[now] = 0
    symcnt[now] += 1
    if symcnt[now] > anscnt:
        ans = now
        anscnt = symcnt[now]
print(ans)

a

Сравнение сложности

Обозначим через \(N\) длину строки, а через \(K\) количество различных символов.

Память здесь учитывается дополнительная, сверх самой входной строки: в противном случае все три решения одинаково требовали бы \(O(N)\), и сравнивать было бы нечего. Первое не хранит ничего, кроме счётчиков; второе строит множество различных значений, встреченных в строке, а третье — словарь тех же значений, вследствие чего оба и требуют \(O(K)\).

Значение алгоритмов для программиста

• Знание алгоритмов способствует эффективному решению задач, встречающихся в работе
• Дополнительная готовность к собеседованию
• Общая когнитивная тренировка

Свойства алгоритмов

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

Дискретность означает, что алгоритм распадается на отдельные шаги, выполняемые по одному и в определённом порядке, а не сливается в одно неделимое действие. Детерминированность — что на одних и тех же входных данных получается один и тот же результат при любом числе запусков алгоритма. Понятность — что каждый шаг посилен исполнителю и не допускает двоякого толкования, вследствие чего инструкция «посолить по вкусу» в алгоритм не годится. Завершаемость — что работа заканчивается за конечное число шагов, а не продолжается бесконечно. Массовость — что алгоритм написан для целого класса входных данных, а не для единственного набора, ради которого он составлялся. Результативность — что на выходе получается ответ, пусть даже им окажется сообщение о том, что решения нет.

Оценка сложности по виду кода

Чаще всего сложность видна в структуре кода, и несколько признаков покрывают большинство случаев:

• Цикл, проходящий по всему массиву, означает линейную сложность
• При вложенном цикле необходимо считать суммарное число итераций внутреннего цикла, а не глубину вложенности. Часто получается произведение длин, но не всегда: у решета Эратосфена два вложенных цикла, а работает оно за \( O(n \log\log n) \)
• Деление пополам, повторяющееся на каждом шаге, означает логарифмическую сложность
• Полный перебор, охватывающий все комбинации, означает экспоненциальную сложность
• Оценку по коду подтверждает измерение: если время растёт как \(N^k\), то при удвоении \(N\) оно возрастает в \(2^k\) раз, а в логарифмических осях зависимость изображается прямой с наклоном \(k\); двух-трёх замеров с удвоением \(N\) достаточно, чтобы отличить линейный алгоритм от квадратичного

Алгоритмически неразрешимые проблемы

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

Существуют задачи, для которых доказано, что решающего их алгоритма не существует; самая известная из них формулируется следующим образом. Пусть даны алгоритм \(A\) и входные данные \(N\); требуется алгоритм, который по этой паре определяет, остановится ли \(A\) на входе \(N\) или будет работать бесконечно. Такого алгоритма не существует, и доказывается это от противного: из предполагаемого распознавателя строится программа, которая поступает наоборот его предсказанию — зацикливается, если распознаватель отвечает «остановится», и останавливается в противном случае, — и эта программа подаётся на вход самой себе.

Ресурсы

• https://tproger.ru/digest/competitive-programming-practice/
• Введение в анализ сложности: https://habr.com/ru/post/196560/
• Гейл Макдауэлл «Карьера программиста»

Бонус. Задача. Поиск простых чисел

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

def is_prime(n):
    if n < 2:
        return False
    i = 2
    while i < n:
        if n % i == 0:
            return False
        i = i + 1
    return True

Эту задачу можно решить быстрее, поскольку делители, превышающие \(\sqrt n\), проверять необязательно.

def is_prime(n):
    if n < 2:
        return False
    i = 2
    while i * i <= n:
        if n % i == 0:
            return False
        i = i + 1
    return True

С помощью функции is_prime(n) можно найти все простые числа, не превосходящие \(n\). Для этого заведём пустой массив smaller_primes и будем проверять на простоту все числа, не превышающие \(n\). Если число простое, добавим его в массив smaller_primes, где в конце работы алгоритма и будет содержаться искомый ответ.

def get_smaller_primes(n):
    smaller_primes = []
    for num in range(2, n + 1):
        if is_prime(num):
            smaller_primes.append(num)
    return smaller_primes

Для практики этот способ слишком медленный: делители для каждого числа перебираются заново. Гораздо быстрее работает решето Эратосфена, известное ещё с древности.

Алгоритм состоит в следующем:

• Выписываются все целые числа от 0 до \(n\). Сразу отмечается, что 0 и 1 не простые (на соответствующих позициях записывается False).
• Заводится переменная \(\mathrm{num}\), равная первому не рассмотренному простому числу. Изначально она равна 2.
• Числа в списке от \(2 \cdot \mathrm{num}\) до \(n\) с шагом, равным \(\mathrm{num}\), помечаются составными. Например, для 2 значением False помечаются чётные числа 4, 6, 8 и так далее.
• Далее переменной \(\mathrm{num}\) присваивается следующее простое число, то есть следующее не рассмотренное число в списке. Для этого достаточно увеличивать \(\mathrm{num}\) с шагом 1, пропуская числа, отмеченные как составные. На первом найденном простом числе достаточно остановиться.
• Два предыдущих шага повторяются, пока это возможно.

В коде это выглядит следующим образом:

def eratosthenes(n):
    if n < 2:
        return [False] * (n + 1)
    numbers = list(range(n + 1))
    numbers[0] = numbers[1] = False
    for num in range(2, n):
        if numbers[num]:
            for j in range(2 * num, n + 1, num):
                numbers[j] = False
    return numbers

eratosthenes(9)

[False, False, 2, 3, False, 5, False, 7, False, False]

Простые числа остались на своих местах, а на позициях, занятых составными числами, стоит False. Ветвь if n < 2 обрабатывает самый маленький тест из таблицы краевых случаев: без неё вызов eratosthenes(0) обращается к элементу numbers[1] списка из одного элемента и завершается исключением IndexError. Алгоритм можно ускорить. Для каждого простого числа \(p\) начнём отмечать составными числа начиная с \(p^2\): всё, лежащее ниже, к этому моменту уже рассмотрено. Внешний цикл при этом достаточно вести до \(\sqrt{n}\): у простых чисел, больших \(\sqrt{n}\), квадрат превосходит \(n\), и отмечать им нечего. Получится следующий код:

import math


def eratosthenes_effective(n):
    if n < 2:
        return [False] * (n + 1)
    numbers = list(range(n + 1))
    numbers[0] = numbers[1] = False
    for num in range(2, math.isqrt(n) + 1):
        if numbers[num]:
            for j in range(num * num, n + 1, num):
                numbers[j] = False
    return numbers

Рассмотрим подробно пример работы алгоритма для \(n = 15\).

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # Запишем числа от 0 до 15

False False 2 3 4 5 6 7 8 9 10 11 12 13 14 15 # Отметим, что 0 и 1 не простые

num = 2 # Пометим все числа, кратные 2, начиная с 4, значением False

False False 2 3 False 5 False 7 False 9 False 11 False 13 False 15

num = 3 # Пометим все числа, кратные 3, начиная с 9, значением False

False False 2 3 False 5 False 7 False False False 11 False 13 False False

num = 5 # Алгоритм можно завершить, так как num**2 больше 15.
              # Все числа, кратные 5 и не превосходящие 15, уже отмечены.

Решето Эратосфена работает за \(O(n \log(\log n))\): для простого \(p\) внутренний цикл выполняет около \(n/p\) отметок, а сумма величин, обратных простым числам, не превосходящим \(n\), растёт как \(\log(\log n)\). Доказательство последнего опирается на нетривиальные факты из теории чисел.

Существует метод решения задачи нахождения всех простых чисел, не превосходящих \(n\), требующий \(O(n)\) операций. Он называется линейным решетом и помечает каждое число как составное только один раз.

Как и прежде, числа перебираются в порядке возрастания, только в отличие от классического решета Эратосфена найденные составные числа не вычёркиваются. Вместо этого для каждого числа \(x\) записывается наименьший простой делитель \(p\). В программе записанный делитель помещается в ячейку массива \(\mathrm{lp}[x]\) (от англ. least prime). Если число простое, его наименьшим простым делителем служит оно само, а если составное, его наименьший простой делитель \(p\) уже встречался раньше. Более того, ранее встречалось и число \(i\), такое, что \(x = i \cdot p\). На шаге \(i\) необходимо пометить число \(x\) как составное и указать его наименьший простой делитель. Каждое число будет помечено только один раз, на шаге \(i = x/p\). Число \(i\) может быть выбрано только одним способом, поскольку у любого числа существует только один наименьший простой делитель \(p\).

Алгоритм состоит в следующем:

• Для каждого числа i в lp[i] хранится минимальный простой делитель этого числа. Заводится массив lp длины n + 1, а также массив primes, в который складываются найденные простые числа.
• Числа i перебираются по возрастанию.
• Если lp[i] = 0, значит, число i простое, и его необходимо добавить в массив primes.
• Рассматриваются все простые числа p, не превосходящие lp[i]. Обновляется lp[p * i] = p.

def get_least_primes_linear(n):
    lp = [0] * (n + 1)
    primes = []
    for i in range(2, n + 1):
        if lp[i] == 0:
            lp[i] = i
            primes.append(i)
        for p in primes:
            x = p * i
            if (p > lp[i]) or (x > n):
                break
            lp[x] = p
    return primes, lp

get_least_primes_linear(8)

([2, 3, 5, 7], [0, 0, 2, 3, 2, 5, 2, 7, 2])

Линейное решето выполняет меньше операций, но это ещё не означает выигрыша во времени. При \(n = 10^6\) решето Эратосфена делает 2 122 048 отметок, а линейное — 921 501 запись, по одной на каждое составное число, однако на машине стенда лекции (CPython 3.12.3, ARM64) первое занимает 60 мс, а второе — 66 мс: каждая итерация линейного решета дороже, и константа перекрывает выигрыш асимптотики.

Резюме

• От алгоритма требуется шесть свойств: дискретность, детерминированность, понятность, завершаемость, массовость и результативность.
• O-нотация описывает, как растёт время работы с ростом объёма данных, отбрасывая константы. Отброшенные множители зависят от процессора и компилятора, характер роста — нет; однако при конкретных размерах данных именно константы решают, какой алгоритм быстрее.
• На миллионе элементов линейный поиск занимает около 12 мс, а бинарный — меньше микросекунды. На больших данных выбранный алгоритм значит больше, чем любая микрооптимизация.
• Пространственная сложность оценивается аналогично, и между временем и занятой памятью почти всегда приходится выбирать.
• Прежде чем оптимизировать, необходимо измерить. Оценка сложности показывает, чего следует ожидать, но реальное время определяется измерением.

Задание. Требуется решить задачи и оценить сложность полученных решений: «Решение задач на Python и анализ сложности».

Основные структуры данных

Скорость программы определяется не только числом операций, выполняемых алгоритмом: не меньшее значение имеет то, как данные расположены в памяти.

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

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

Слайды к главе. Представление базовых типов, объекты Python и сборка мусора, массивы постоянного размера и динамические массивы, реаллокация и амортизация изложены также в третьей части лекции «Алгоритмы и сложность» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Оперативная память и представление данных

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

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

Устройство оперативной памяти

Оперативная память, или ОЗУ, служит программе черновиком для вычислений: в неё можно записывать и перезаписывать информацию, а записанное — считывать обратно.

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

Оперативная память разбита на ячейки размером в 1 байт, и у каждой ячейки есть свой порядковый номер, называемый «адресом» (отдельные биты внутри ячейки адресов не имеют). Процессор, работающий с оперативной памятью напрямую, обращается к данным по адресам почти так же, как программа обращается к переменным по имени.

Чтобы понять, сколько памяти потребляет программа, необходимо выяснить, сколько места занимают отдельные созданные объекты. В разных языках программирования занятый объём может отличаться, но основные принципы остаются общими. Рассмотрение начнём с языка C++, позволяющего использовать память эффективно, гибко и предсказуемо.

Представление базовых типов данных в ОП

Наименьшая ячейка имеет размер в 1 байт, состоящий из 8 бит. Каждый бит принимает одно из двух значений: 0 или 1. Восемь бит позволяют закодировать \(2^8 = 256\) вариантов, поэтому в такую ячейку можно записать, например, целое число, лежащее в промежутке от 0 до 255.

Если считать записанные числа номерами символов, то в 1 байт умещается один символ ASCII (тип char): латиница, цифры и основные знаки препинания занимают меньше 128 кодов. Для кириллицы места уже не хватает: в однобайтовых кодировках наподобие CP1251 она размещена в верхней половине таблицы, а в UTF-8, принятом сегодня по умолчанию, каждая русская буква занимает два байта — отсюда расхождение между len(text) и len(text.encode()), о котором шла речь в главе «Объекты и память».

Самый распространённый тип целых чисел int занимает 4 байта и позволяет закодировать числа от −2 147 483 648 до 2 147 483 647.

Границы легко вычислить. В 4 байтах содержится 32 бита, то есть \(2^{32}\) различных комбинаций. В дополнительном коде, которым представлены целые со знаком, старший бит отвечает за знак: \(2^{31} = 2;147;483;648\) комбинаций отведены отрицательным числам от \(-2^{31}\) до \(-1\), ещё \(2^{31}\) — неотрицательным от 0 до \(2^{31} - 1\). Ноль занимает один из неотрицательных кодов, поэтому положительных чисел на одно меньше, чем отрицательных.

Если числа не превышают по модулю два миллиарда, этого типа достаточно. Всего значений около четырёх миллиардов, но половина из них отрицательные. Если точно известно, что переменная не может быть отрицательной, подходит тип беззнаковых целых unsigned int, хранящий числа от 0 до 4 294 967 295.

Вещественные (то есть дробные) числа чаще всего кодируются типом double, «числами с плавающей точкой», занимающими 8 байт. Восьми байт хватает и на очень большие числа, такие как \(\pm10^{308}\), и на близкие к нулю, например \(\pm10^{-308}\).

Диапазон, однако, не то же самое, что точность. Под мантиссу, цифровую часть числа, из восьми байт отведено 52 бита, и ещё один старший бит подразумевается, поэтому точность составляет 53 двоичных разряда, или примерно шестнадцать значащих десятичных цифр; всё, что за них не поместилось, отбрасывается округлением. Расстояние от единицы до следующего представимого числа называется машинным эпсилон и равно \(2^{-52} \approx 2{,}2\cdot10^{-16}\); добавка, которую единица ещё различает при округлении к ближайшему, вдвое меньше: 1 + 1.2e-16 != 1, хотя \(1{,}2\cdot10^{-16}\) меньше эпсилон. Шаг между соседними представимыми числами не постоянен, а растёт вместе с самим числом, оставаясь относительным. Отсюда 0.1 + 0.2 != 0.3: ни одна из этих дробей в двоичной записи не конечна, и сумма отклоняется от ответа на последние биты. Отсюда же следует и потеря точности при вычитании близких величин: старшие цифры, которыми они совпадали, взаимно уничтожаются, и от разности остаётся столько верных цифр, сколько их было в различающейся младшей части.

Составные типы данных

Подсчитаем, сколько памяти потребуется для хранения массива, составленного из 10 строк по 20 символов каждая.

Во-первых, потребуется хранить сам текст. Это займёт $$10; \text{строк} \cdot (20; \frac{\text{символов}}{\text{строка}}) \cdot (1;\frac{\text{байт}}{\text{символ}}) = 200; \text{байт}$$ Этого было бы достаточно, если бы строки располагались в памяти друг за другом, но выполнять с ними операции в таком случае было бы сложно.

Поэтому в массивы (и в другие составные структуры) зачастую помещаются не сами объекты, а только указатели на них, то есть адреса ячеек, отведённых под эти объекты в оперативной памяти.

Во многих других языках каждый объект в программе записан в специальную «обёртку», содержащую, помимо данных, вспомогательную информацию. Из-за такой обвязки в Python даже короткие целые числа занимают не 4 байта, а почти 30. Для хранения строки требуется около 40 байт служебных данных (в CPython 3.12 — 40 байт у строк из символов ASCII и 56 у остальных, в 3.11 — 48 и 72), а для хранения массива и того больше. Объекты в таких языках ведут себя как строки из примера выше: они могут находиться в произвольном месте памяти, и любое обращение к ним осуществляется по сохранённому адресу.

Подсчитаем, сколько памяти расходует массив, собранный из 10 чисел в Python, и на что она уходит:

import sys
print(sys.getsizeof(42))  # => 28 байт занимает короткое целое число
print(sys.getsizeof([]))  # => 56 байт занимает пустой массив
print(sys.getsizeof([42]))  # => 64 = (56 + 8) байт занимает массив с одним элементом.
print(sys.getsizeof([1,2,3,4,5,6,7,8,9,10]))  # => 136 = (56 + 8*10) байт занимает массив
                               # с десятью элементами.
                               # числа 1-10 берутся из кеша малых целых;
                               # десять различных больших чисел
                               # добавили бы ещё 280 = (28 * 10) байт

56 байт уходит на сам массив и по 8 байт на адрес каждого элемента. Если числа различны и не попадают в кеш малых целых (от −5 до 256), к этому добавляется ещё по 28 байт на каждое число, и массив из десяти чисел занимает 56 + (8 + 28) * 10 байт = 416 байт против 40 байт в C++; числа из кеша хранятся в одном экземпляре, и тогда на список приходится лишь 136 байт — заголовок и ссылки. Размеры приведены для CPython 3.11 и 3.12 на 64-битной платформе; в 3.9 тот же литерал из десяти чисел занимает 152 байта.

Освобождение памяти

Если программа перестала пользоваться объектом, это ещё не означает, что занимаемая им память освобождена. В языке C++ необходимо следить за тем, чтобы выделенная память освобождалась. Встроенные контейнеры наподобие std::vector сами выделяют память при создании и отдают её обратно, когда переменная, хранящая контейнер, выходит из области видимости.

В большинстве других языков за освобождение памяти отвечает сборщик мусора, время от времени находящий объекты, до которых программа больше не может добраться ни через переменные, ни через другие объекты; такие объекты уничтожаются, даже если ссылаются друг на друга. CPython сочетает два механизма: объект, на который не осталось ни одной ссылки, подсчёт ссылок уничтожает сразу, а циклические структуры обнаруживает отдельный сборщик циклов, модуль gc.

Сборка мусора является трудоёмкой операцией, поэтому некоторые языки откладывают её до тех пор, пока свободное пространство не подойдёт к концу. Например, программы на Java (если их специально не ограничить при запуске) часто сталкиваются с высоким потреблением памяти из-за множества старых, уже неиспользуемых объектов, сохраняемых до очередной сборки.

Массивы постоянного размера

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

Самый простой тип массивов имеет фиксированный размер и хранит элементы одного и того же типа. Например, в созданный массив из десяти целых чисел нельзя добавить ещё один элемент или записать объект неподходящего типа. Такие массивы встречаются в языке C как int numbers[10], а в C++ как std::array<int, 10> numbers.

С массивами фиксированного размера можно выполнить только две операции:

• получить значение элемента по заданному индексу,
• перезаписать значение по указанному индексу.

Обе операции выполняются за \(O(1)\).

Устройство массива

Массив представляет собой набор однотипных данных, расположенных в памяти друг за другом, поэтому он всегда занимает один непрерывный участок. Адрес выделенного участка программа получает в момент создания массива от распределителя памяти — функции malloc и её аналогов — или от указателя стека.

В начале выделенного участка памяти находится нулевой элемент, сразу за ним первый и далее по порядку, друг за другом, без пропусков. Зная адрес элемента, его можно прочитать или записать. Непрерывное расположение даёт и преимущество, не видное в O-нотации: процессор загружает память строками кеша по 64–128 байт, и последовательный проход по массиву использует каждую загруженную строку целиком.

Пусть имеется массив numbers из 10 целых чисел типа int, адрес нулевого элемента которого равен 1000. Адрес следующего элемента равен адресу начала плюс размер элемента в байтах. Каждое число занимает по 4 байта, и нулевой элемент займёт байты 1000, 1001, 1002, 1003. Следовательно, элемент с индексом 1 будет записан по адресу 1004.

Сложность вставки и удаления в динамических массивах

Динамические массивы иногда называют «векторами», потому что в C++ они реализуются классом std::vector. В Python динамический массив скрыт за классом list, и, несмотря на название, это не список, а массив.

Сложность вставки в динамический массив

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

Элемент можно вставить в любое место массива; вставка в начало и в конец являются частными случаями. Худший случай — вставка в начало, поскольку все лежащие правее элементы приходится сдвинуть на одну позицию, а это \(O(n)\). Добавление в конец — лучший случай: сдвигать ничего не нужно, и стоимость операции составляет \(O(1)\), пока в выделенном участке есть свободное место.

Сложность удаления из динамического массива

При удалении, как и при вставке, приходится сдвигать все элементы, стоящие правее затронутой ячейки: при добавлении — на один вправо, при удалении — на один влево. Стоимость та же: \(O(n)\) при работе с началом массива и \(O(1)\) при работе с концом.

Реаллокация в динамических массивах

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

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

Выделение памяти является долгой операцией, а копирование обходится ещё дороже: пройти придётся по всем записанным элементам, а это \(O(n)\). Возникает вопрос, почему добавление в конец массива при этом стоит \(O(1)\).

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

values = []
for i in range(1000):
    values.append(i)

Операцию append() можно представить как две: реаллокацию и присваивание значения элементу массива. Операции присваивания учитывать не будем: их число равно количеству добавляемых элементов и оптимизации не поддаётся. Время же реаллокаций зависит от выбранного подхода.

Если бы реаллокация происходила при каждом добавлении элемента, сложность оказалась бы квадратичной.

Во-первых, чтобы не приходилось на каждом шаге выделять дополнительную память, необходимо держать запас свободного места в массиве. Например, если увеличивать размер сразу на 100 элементов, программа будет запрашивать память в 100 раз реже. Однако такая программа всё ещё работает за \(O(n^2)\), хотя и с небольшой константой при квадратичном члене.

Таким образом, у массива появляются два разных размера: size (количество занятых ячеек) и capacity (ёмкость выделенного участка), причём size ≤ capacity.

Во-вторых, чтобы сделать сложность алгоритма линейной, необходимо увеличивать размер не на фиксированное количество элементов (арифметическая прогрессия), а в заданное число раз (геометрическая прогрессия).

Пусть изначальная ёмкость массива равна 1, а при каждой реаллокации она удваивается. Тогда на первой реаллокации копируется 1 элемент, на второй — 2, на третьей — 4, затем 8, 16, 32, 64, 128, 256 и 512, после чего накопленная ёмкость равна 1024.

Общее число копирований к моменту добавления 1000-го элемента: \(S = 1 + 2 + 4 + \cdots + 512 = 1024 - 1\).

В общем случае, если необходимо добавить \(n\) элементов, где \(2^k \lt n \le 2^{k+1}\), последнее копирование затронет \(2^k\) элементов. Запишем сумму получившейся геометрической прогрессии: \(S = \sum_{i=0}^k 2^i = 2^{k+1} - 1 = 2 \cdot 2^k - 1 \le 2\cdot n\).

Следовательно, общее количество копирований при реаллокациях линейно зависит от числа добавленных элементов. В общем случае при росте ёмкости в \(r\) раз на один элемент приходится меньше \(r/(r-1)\) копирований. Список CPython растёт не вдвое, а примерно в 1,125 раза: новая ёмкость вычисляется как newsize + (newsize >> 3) + 6 с округлением вниз до кратного четырём. Копирований при этом больше — не больше девяти на элемент вместо двух, — но их число по-прежнему линейно зависит от числа элементов, а запас ёмкости у больших списков составляет до 12,5 %.

Слайды к главе. Связный список, стек, очередь и дек, сравнение списка и дека и выбор структуры изложены также в четвёртой части лекции «Алгоритмы и сложность»; слайды лекции доступны на сайте книги и в PDF.

Связные списки

Элементы массива в памяти компьютера расположены последовательно. Чтобы вставить или удалить элемент из начала массива, требуется \(O(n)\) операций, потому что передвинуть придётся каждый элемент, стоящий следом.

Структурой, не требующей при вставке или удалении сдвигать остальные элементы, является связный список (англ. linked list); он присутствует в стандартных библиотеках многих языков: std::list в C++, LinkedList в Java.

В языке Python list остаётся динамическим массивом, хотя и обозначен словом «список».

Устройство связного списка

В связном списке у каждого элемента, помимо его значения, есть ссылка на следующий элемент списка, за исключением последнего, ссылающегося в никуда. В зависимости от языка программирования ссылка в никуда может представлять собой объект None, нулевой указатель или аналогичную сущность. У связного списка определяют точку старта, называемую «головой списка».

Достоинства и недостатки связного списка

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

Платой за это является доступ по индексу: элементы лежат вразброс, и до нужного приходится идти от головы списка, перебирая все звенья по дороге, а это \(O(n)\) операций.

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

Структура данных стек

Стек работает по принципу LIFO (англ. last in, first out, «последним пришёл, первым ушёл»). Извлечь можно только элемент, положенный последним.

На стеке реализована кнопка «назад» в браузере: одно нажатие возвращает на предыдущую страницу, следующее — на открытую перед ней.

Отмена последних операций в текстовых редакторах также реализована на стеке.

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

Интерфейс стека

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

• push(item) добавляет элемент на вершину стека;
• pop() возвращает элемент с вершины стека и удаляет его;
• size() возвращает размер стека (количество лежащих в нём элементов).

Иногда присутствуют дополнительные операции:

• peek() или top() возвращает элемент с вершины стека, не удаляя его;
• isEmpty() определяет, пуст ли стек.

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

Реализация стека

Стек на основе массива: в конструкторе создаётся пустой массив, а методы push() и pop() его изменяют:

class Stack:
    def __init__(self):
        self.items = []

    def push(self, item):
        self.items.append(item)

    def pop(self):
        return self.items.pop()

    def peek(self):
        return self.items[-1]

    def size(self):
        return len(self.items)

stack = Stack()
stack.push('apple')
stack.push('banana')
stack.push('orange')

print(stack.pop())  # orange

Структуры данных: очередь и дек

Очередь, в отличие от стека с его LIFO, работает по принципу FIFO (англ. first in, first out): первым извлекается элемент, добавленный раньше всех.

Бытовые очереди подчиняются тому же правилу:

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

Такие сценарии моделируются структурой данных очередь.

Интерфейс очереди

Как и стек, очередь задаёт интерфейс взаимодействия с данными, гарантирующий набор методов, но не способ их хранения. Очередь принято реализовывать так, чтобы и вставка, и удаление элемента стоили \(O(1)\).

Методы очереди:

• push(item) добавляет элемент в конец очереди;
• pop() берёт элемент из начала очереди и удаляет его;
• peek() берёт элемент из начала очереди без удаления;
• size() возвращает количество элементов в очереди.

Дек: очередь с двумя концами

Очередь пропускает элементы только в одну сторону: вход через хвост, выход через голову. Дек (deque, от double-ended queue, двусторонняя очередь) позволяет добавлять и удалять элементы с любого конца, и обе операции выполняются за \(O(1)\).

Аналогией служит колода карт в руках: карту можно взять или подложить сверху или снизу, а извлечь из середины, не нарушив колоду, не удастся.

Интерфейс дека объединяет стек и очередь:

• append(item) добавляет элемент в конец;
• appendleft(item) добавляет в начало;
• pop() берёт элемент с конца и удаляет;
• popleft() берёт с начала и удаляет.

Дек обобщает обе структуры: работа с одним концом даёт стек, вход с одного конца и выход с другого — очередь. Отдельного класса простой очереди для однопоточного кода в Python нет, её роль выполняет дек; классы queue.Queue и queue.SimpleQueue из стандартной библиотеки решают другую задачу — обмен данными между потоками, — и queue.Queue внутри содержит тот же дек.

В стандартной библиотеке дек находится в модуле collections:

from collections import deque

buf = deque()
buf.append(1)          # [1]
buf.append(2)          # [1, 2]
buf.appendleft(0)      # [0, 1, 2]

print(buf.popleft())   # 0, забрали из начала
print(buf.pop())       # 2, забрали с конца
print(buf)             # deque([1])

Преимущества дека перед списком

Список в Python поддерживает и insert(0, x), и pop(0); разница заключается в стоимости. Список устроен как динамический массив, его элементы лежат в памяти подряд; чтобы вставить элемент в начало, необходимо сдвинуть все остальные на одну позицию вправо, а это \(O(n)\) на каждую вставку. Дек устроен как цепочка связанных между собой блоков по 64 ссылки, и добавление к любому его концу не затрагивает уже уложенные элементы.

Замер на Apple M4, заполнение структуры с начала:

      N |      list |     deque | отношение
   1000 |    0.19 мс |  0.015 мс |     13x
  10000 |   13.09 мс |  0.122 мс |    107x
 100000 | 1358.53 мс |  1.364 мс |    996x

Важны не сами числа, а последний столбец. Отношение растёт вместе с \(N\), и это является признаком разной алгоритмической сложности. Если бы дек был просто реализован эффективнее, выигрыш оставался бы постоянным. Здесь же на тысяче элементов разница тринадцатикратная, на ста тысячах — тысячекратная, потому что время списка растёт как \(O(n^2)\), а время дека как \(O(n)\). На машине стенда лекции (CPython 3.12.3, ARM64) тот же замер дал отношения 7, 48 и 406: абсолютные значения зависят от машины и версии интерпретатора, а рост отношения с \(N\) сохраняется.

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

buf = []
for x in data:
    buf.append(x)
    if len(buf) > 1000:
        buf.pop(0)         # удаление из начала — O(n)

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

buf = deque(maxlen=1000)
for x in data:
    buf.append(x)          # старое значение уходит само, O(1)

На потоке из 200 000 отсчётов первый вариант отработал за 21 мс, а второй за 2 мс: порядок, выигранный одной строкой в выборе структуры данных.

Дек платит за это доступом по индексу. У списка элементы лежат подряд, поэтому lst[50000] вычисляется арифметикой по адресу за \(O(1)\). У дека до середины приходится добираться по блокам, перебирая сцепленные звенья, и это \(O(n)\). В том же замере обращение к середине заняло 0,005 мкс у списка против 0,525 мкс у дека, то есть примерно в сто раз дольше.

Правило выбора, работающее почти всегда: если нужен произвольный доступ по индексу — список; если нужны быстрые операции с обоими концами, а середина лишь пробегается целиком — дек. insert(0, x) или pop(0) внутри цикла почти наверняка означают, что требуется дек.

Слайды к главе. Стек вызовов и его кадры, пределы глубины рекурсии и их зависимость от версии Python, замена рекурсии циклом изложены также в пятой части лекции «Алгоритмы и сложность»; слайды лекции доступны на сайте книги и в PDF.

Стек вызовов

Код программы разделён на функции: базовые объединяются в сложные, а те в ещё более сложные, и вся программа представима как одна функция, вызывающая множество других.

Устройство стека вызовов

Допустим, написана программа на C++. Первой вызывается функция main(), в которой вызывается функция A. Она вызывает функцию B, которая, в свою очередь, вызывает C.

Стек вызовов написанной программы выглядит следующим образом:

        вершина стека
   ┌──────────────┐
   │      C       │  ← выполняется сейчас
   ├──────────────┤
   │      B       │  вызвала C
   ├──────────────┤
   │      A       │  вызвала B
   ├──────────────┤
   │    main()    │  вызвала A
   └──────────────┘
         дно

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

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

def say_hello(name):
    print(f"Привет, {name}")
    print_horoscope(name.upper())
    print(f"Пока, {name}, хорошего дня!")

def print_horoscope(name):
    print(f"{name}! Сегодня подходящий день для прогулок в парке и изучения рекурсии")

say_hello('Гоша')

В разных частях программы переменная name хранит разные значения: при входе в say_hello() в ней записано 'Гоша', в print_horoscope() — 'ГОША', а после возврата в say_hello() снова 'Гоша'.

Для этого программа хранит локальные переменные на том же стеке: на вершине лежит структура с локальными переменными, аргументами функции и адресом возврата, называемая кадром стека (англ. stack frame); ниже она для наглядности называется блоком. Проследим, как меняется стек в этом примере.

Работа стека: шаг за шагом

Первая команда программы — вызов say_hello(), под который на стеке выделяется блок памяти.

   ┌────────────────────┐
   │  say_hello()       │  ← выделен блок под вызов
   └────────────────────┘

В блок записывается адрес возврата — адрес инструкции, следующей сразу за местом вызова функции.

Туда же помещаются аргументы, с которых начинается набор локальных переменных. Здесь один аргумент name = 'Гоша', других локальных переменных нет.

   ┌────────────────────┐
   │  say_hello()       │
   │    адрес возврата  │
   │    name = 'Гоша'   │
   └────────────────────┘

Первая инструкция say_hello() выводит «Привет, Гоша». Затем метод upper() возвращает строку 'ГОША', и она становится параметром print_horoscope().

Вызовы print() и upper() на схеме не показаны, хотя они также помещаются на стек при вызове и снимаются с него после завершения.

При вызове print_horoscope() с параметром 'ГОША' выделяется новый блок памяти с параметрами, адресом возврата и местом под локальные переменные. Он ложится поверх блока say_hello() — та же стопка книг в коробке, только из блоков памяти.

   ┌────────────────────┐
   │  print_horoscope() │  ← новый блок лёг сверху
   │    адрес возврата  │
   │    name = 'ГОША'   │
   ├────────────────────┤
   │  say_hello()       │
   │    адрес возврата  │
   │    name = 'Гоша'   │
   └────────────────────┘

Первая инструкция print_horoscope() выводит «ГОША! Сегодня подходящий день для прогулок в парке и изучения рекурсии».

Инструкций в print_horoscope() больше нет, и управление возвращается по адресу, записанному в её блоке. Блок снимается со стека, и на вершине снова оказывается блок say_hello(), в котором переменная name по-прежнему хранит 'Гоша'.

   ┌────────────────────┐
   │  say_hello()       │  ← верхний блок снят,
   │    адрес возврата  │    name снова 'Гоша'
   │    name = 'Гоша'   │
   └────────────────────┘

Затем исполняется инструкция say_hello(), следующая за вызовом print_horoscope(), и выводит «Пока, Гоша, хорошего дня!»

Это последняя инструкция say_hello(), поэтому происходит возврат из функции, и её блок освобождается.

   ┌────────────────────┐
   │                    │  ← стек пуст
   └────────────────────┘

Рекурсия. Переполнение стека вызовов

Функции, вызывающие сами себя с изменёнными аргументами, называются рекурсивными, и они также используют стек вызовов.

Здесь речь идёт о цене, которую рекурсия платит стеком; как рекурсия записывается, из чего складываются рекурсивный и базовый случаи и какие ошибки при этом типичны, рассматривается далее, в главе «Рекурсия и сортировки».

Факториал

Факториал натурального числа можно вычислить как произведение всех натуральных чисел от 1 до n: \(n! = 1 \cdot 2 \cdot ... \cdot (n-1) \cdot n\)

Рекурсия и стек вызовов

Рекурсивная функция вычисления факториала:

def factorial(n):
    if n == 1 or n == 0:
        return 1
    return n * factorial(n - 1)

Вызов factorial(3):

   Погружение:                    Возврат:
   ┌──────────────┐               ┌──────────────┐
   │ factorial(1) │ вернёт 1      │ 1            │
   ├──────────────┤               ├──────────────┤
   │ factorial(2) │ ждёт          │ 2 * 1 = 2    │
   ├──────────────┤               ├──────────────┤
   │ factorial(3) │ ждёт          │ 3 * 2 = 6    │
   └──────────────┘               └──────────────┘

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

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

Чтобы хранить локальные переменные и адрес возврата на каждом уровне рекурсии, потребуется \(O(d)\) памяти на стеке, где d — глубина рекурсии. При вычислении факториала \(n!\) глубина равна n, поэтому приведённая выше функция расходует \(O(n)\) памяти на стеке.

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

Ограничений два. Первое устанавливает сам Python: по умолчанию около тысячи вложенных вызовов, далее RecursionError, а поднять порог можно через sys.setrecursionlimit. Второе — стек операционной системы, обычно 8 МБ; достичь его можно, только сняв первое. Здесь важна версия. По Python 3.10 включительно каждый вызов питоновской функции рекурсивно вызывал функцию интерпретатора на C и расходовал стек C, поэтому глубже нескольких десятков тысяч вызовов рекурсию довести было нельзя: на CPython 3.9 со стеком 8 МБ глубина 30 000 проходит, а на 50 000 процесс завершается аварийно. Начиная с 3.11 вызов одной питоновской функции из другой обходится без рекурсии на C, и чистая рекурсия с поднятым порогом доходит до миллиона уровней, расходуя память кучи. Однако когда цепочка вызовов уходит через C (например, через __repr__), стек C расходуется на каждом уровне. В 3.11 такая рекурсия на глубине в несколько десятков тысяч уровней переполняет стек (англ. stack overflow), а в 3.12 её ограничивает отдельный механизм, и вместо аварийного завершения возникает RecursionError. В одних языках при переполнении стека возникает исключение «Stack Overflow», в других ошибка «Segmentation Fault».

factorial(10_000)  # завершится исключением RecursionError

Предотвращение переполнения стека

Приёмы против переполнения стека:

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

def factorial(n):
    accumulator = 1
    i = n
    while i > 1:
        accumulator *= i
        i -= 1
    return accumulator

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

Объёмом памяти под стек вызовов можно управлять. В некоторых языках — непосредственно во время работы программы: в Python функция sys.setrecursionlimit() задаёт максимальную глубину рекурсии, а sys.getrecursionlimit() возвращает текущее значение; фактический предел определяется памятью и, для вызовов через код на C, размером стека потока. В Java и JavaScript размер стека вызовов задаётся настройками виртуальной машины при запуске и во время работы не меняется. Иногда размер стека вызовов можно изменить на уровне операционной системы.

import sys
print(sys.getrecursionlimit())  # 1000

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

Резюме

Сводная таблица для выбора структуры под задачу:

\(^*\) Амортизированно: изредка происходит реаллокация, но в среднем на каждый добавленный элемент приходится константа.

\(^{**}\) В том виде, в каком список описан выше, с одной только головой: чтобы добавить элемент в конец, приходится пройти весь список. Если хранить ещё и ссылку на хвост, вставка в конец становится \(O(1)\), и так устроены реализации, принятые в стандартных библиотеках.

Универсальной структуры не существует, существует подходящая под задачу. Если элементы постоянно добавляются и снимаются с обоих концов, а в коде используется список, программа платит \(O(n)\) там, где могла бы платить \(O(1)\).

Ни одна из рассмотренных структур не позволяет быстро искать по значению, все дают \(O(n)\). Как обойти это ограничение, рассматривается в следующих главах, посвящённых хеш-таблицам и деревьям поиска.

Рекурсия и сортировки

Настоящая глава начинается с рекурсии, для многих первого трудного места в программировании, после чего рекурсия применяется к самой изученной задаче информатики — сортировке.

Слайды к главе. Рекурсивный и базовый случаи, замена рекурсии циклом и явным стеком, рекурсивный перебор вариантов изложены также в пятой части лекции «Алгоритмы и сложность» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Введение. Примеры задач на рекурсию

Пусть требуется найти файл Kormen.pdf в папке C:\books\, заполненной вложенными подпапками, без поиска, встроенного в файловый менеджер. Возможны два варианта.

Первый — обычный обход списком:

   Обходим папки списком, вручную запоминая, куда ещё не заходили:

   очередь: [C:\books]
   → зашли в C:\books, нашли подпапки: algo, physics, math
   очередь: [algo, physics, math]
   → зашли в algo, нашли подпапку: sorting
   очередь: [physics, math, sorting]
   → зашли в physics … и так далее, пока не найдётся файл или не опустеет очередь

Второй — тот же поиск, записанный рекурсивно:

   найти(C:\books)
   ├── найти(algo)
   │   └── найти(sorting) ──▶ Kormen.pdf найден!
   ├── найти(physics)    ← не вызывается: файл уже найден
   └── найти(math)       ← не вызывается

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

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

Рекурсивный и базовый случаи

Любая корректно работающая рекурсия состоит из двух обязательных частей:

• рекурсивного случая, запускающего прямой ход рекурсии и её углубление;
• базового случая, который в нужный момент останавливает это углубление и запускает обратный ход рекурсии.

Рекурсивный случай

Рассмотрим заготовку функции, строящей лестницу из n ступеней:

функция stairs_builder(n):
    построить 1 ступеньку
    print("Осталось построить {n - 1} ступеней.")
    stairs_builder(n - 1)

Вызов функцией самой себя с изменёнными параметрами, stairs_builder(n - 1), и есть рекурсивный случай. Однако программа, написанная таким образом, не остановится сама: рекурсия, лишённая условия остановки, будет углубляться, пока не исчерпает стек вызовов или не упрётся в предел глубины; в Python предел срабатывает примерно через тысячу вызовов, и программа завершается исключением RecursionError.

На каждом следующем уровне рекурсии число непостроенных ступеней n уменьшается на 1. Но после n = 0 функция, не знающая базового случая, не остановит работу, а вызовется со значением −1, затем с −2 и так далее. При неограниченных ресурсах лестница строилась бы вечно.

Базовый случай

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

Рекурсия в stairs_builder() должна остановиться, когда построено заданное количество ступеней, то есть когда счётчик, уменьшаемый на каждом уровне, дойдёт до n = 0. Это и есть базовый случай.

функция stairs_builder(n):
  if n == 0:
    return
  построить 1 ступеньку
  print("Осталось построить {n - 1} ступеней.")
  stairs_builder(n - 1)

Правильное построение рекурсии

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

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

Базовый случай описывает ситуацию, требующую остановки: результат, возвращаемый функцией здесь, вычисляется явно, без обращения к рекурсивным вызовам.

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

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

В большинстве случаев программа, ушедшая в бесконечную рекурсию, не будет работать вечно, а завершится с ошибкой переполнения стека вызовов или с ошибкой сегментации (англ. segmentation fault): каждый вызов, добавленный в стек, расходует память, а она ограничена. Поведение программы зависит и от самого алгоритма, и от используемого компилятора. Подробнее об этом можно прочитать в статье про оптимизацию хвостовой рекурсии (англ. tail call optimization). CPython такой оптимизации не выполняет: хвостовая рекурсия расходует стек так же, как обычная.

Разбор задач. Рекурсивный перебор вариантов

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

Генерация последовательностей из 0 и 1

Рассмотрим генерацию всех последовательностей длины n, составленных из нулей и единиц.

Функция принимает число n и строку prefix, накапливающую уже выбранные символы. Вызовем её со значением prefix, равным пустой строке, чтобы далее дописывать в неё 0 и 1. В каждом рекурсивном вызове n означает, сколько символов ещё не дописано. Рекурсия останавливается, когда n = 0: строка, собранная к этому моменту, готова, и это базовый случай рекурсии.

В рекурсивном случае функция вызывает себя дважды, но с разными параметрами: в первый раз к строке prefix приписывается цифра 0, а во второй 1. Значение n, переданное вниз, каждый раз уменьшается на 1, а prefix удлиняется на один символ. Таким образом рекурсия уходит на n уровней в глубину, и каждый её лист отвечает одной построенной последовательности.

Решение этой задачи удобно представлять в виде бинарного дерева, растущего вниз от пустой строки. Переход влево соответствует приписыванию 0, переход вправо — приписыванию 1. Пройдя от корня по всем ветвям, получим все последовательности длины 3, составленные из 0 и 1.

                    «»
              ┌─────┴─────┐
             0             1
          ┌──┴──┐       ┌──┴──┐
         00     01     10     11
        ┌─┴─┐  ┌─┴─┐  ┌─┴─┐  ┌─┴─┐
      000 001 010 011 100 101 110 111

Рекурсия часто используется для перебора вариантов. Пусть имеется n различных предметов, каждый из которых может быть взят или отложен в сторону. Тогда наборов, собираемых из них, ровно \(2^n\). Пронумеруем предметы числами от 1 до \(n\) и опишем набор строкой, где предмет, взятый в набор, помечен цифрой 1, а отложенный — цифрой 0. Таким образом, задача перебора вариантов сводится к уже рассмотренной задаче генерации последовательностей.

def generate(n, prefix):
    if n == 0:
        print(prefix)
        return
    generate(n - 1, prefix + '0')
    generate(n - 1, prefix + '1')

generate(3, '')

000
001
010
011
100
101
110
111

Время перебора растёт как \(2^n\). В демонстрации лекции на машине стенда (CPython 3.12.3, ARM64) одна конфигурация обходится примерно в 63 нс, и полный перебор при \(n = 40\) занял бы около 19 часов, а при \(n = 64\) — около 37 000 лет; ускорение в тысячу раз позволяет добавить лишь десять разрядов.

Слайды к главе. Устойчивость и ключ, сортировки слиянием и быстрая, встроенная сортировка Python и сортировка подсчётом изложены также в шестой части лекции «Алгоритмы и сложность»; слайды лекции доступны на сайте книги и в PDF.

Алгоритмы сортировки. Знакомство

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

Сортировки среди нас

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

Роль сортировок в решении задач

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

• найти элемент в массиве быстрее чем за \(O(n)\), воспользовавшись бинарным поиском, возможно только на отсортированных данных;
• таблицу «10 лучших студентов курса» проще собрать из списка, упорядоченного не по алфавиту, а по среднему баллу.

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

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

Выбор алгоритма сортировки

Сравним два алгоритма, решающих одну и ту же задачу:

• один работает быстро, но требует \(O(n)\) дополнительной памяти;
• другой алгоритм медленнее, но ему требуется лишь \(O(1)\) дополнительной памяти.

Пусть в компании стоят старые серверы, свободной памяти на которых почти не осталось. На одном из них лежат данные об удовлетворённости жизнью, собранные по всем городам страны. Для ежемесячного отчёта их необходимо отсортировать и выбрать названия 100 городов с самыми довольными жителями. Отчёт требуется сдать через неделю.

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

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

Здесь предпочтительнее более быстрый алгоритм, но требующий больше памяти.

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

• Срочность ответа. Если результат сортировки нужен не срочно, подходит более медленный алгоритм, зато не требующий лишней памяти.
• Объём данных, поступающих на вход. Если в массиве всего 1000 элементов, то любой алгоритм сортировки упорядочит их за неощутимое время. На 5 000 000 элементов разница между алгоритмами становится решающей.
• Объём доступной памяти. Если свободного места хватает на вторую копию массива, можно собирать отсортированный массив в выделенной памяти, а не переставлять элементы в исходном.

Устойчивость сортировок

Сортировку, сохраняющую взаимный порядок элементов с равным значением сравниваемого признака, называют устойчивой (англ. stable sort). Если же равные элементы могут поменяться местами, сортировку называют неустойчивой. Разница важна, когда данные сортируют несколько раз подряд по разным ключам: устойчивая сортировка сохраняет результат, полученный на предыдущем проходе, а неустойчивая его перемешивает.

Сортировка по ключу

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

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

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

• В одном варианте передаётся функция одного аргумента key(object). Она даёт значение ключа для каждого объекта, и объекты попарно сравниваются по вычисленным ключам.
• В другом варианте передаётся функция двух аргументов less(object_1, object_2), сравнивающая два объекта напрямую: она возвращает true, если первый должен стоять раньше второго, и false в противном случае. Такую функцию называют «компаратор» (англ. compare, «сравнивать»).

Компаратор задаёт порядок гибче, чем ключ: сортировку по любому ключу легко переписать через компаратор:

функция less(object_1, object_2):
    return key(object_1) < key(object_2)

Обратное преобразование выполняет обёртка functools.cmp_to_key; однако компаратор вызывается на каждом сравнении и не всякий компаратор задаёт корректный порядок, поэтому обычно проще пользоваться функцией, вычисляющей ключ сортировки.

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

Сортировка слиянием

Сортировка слиянием (англ. merge sort) работает за \(O(n \log n)\) даже в худшем случае.

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

Алгоритм складывается из трёх действий, повторяемых на каждом уровне:

• Массив разбивается на две части примерно одинакового размера.
• Если в подмассиве, полученном при разбиении, больше одного элемента, то для него рекурсивно запускается тот же алгоритм, начиная с первого шага.
• Два упорядоченных массива соединяются в один.

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

   Разбиение:                        Слияние:
        [5 2 9 1]                      [1 2 5 9]
        ┌────┴────┐                    ┌────┴────┐
      [5 2]     [9 1]                [2 5]     [1 9]
      ┌─┴─┐     ┌─┴─┐                ┌─┴─┐     ┌─┴─┐
     [5] [2]   [9] [1]              [5] [2]   [9] [1]

Дерево алгоритма сортировки слиянием: массив разбивается на части примерно равной длины. Каждая часть сортируется рекурсивно, после чего части, приведённые в порядок, объединяются в единый массив

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

def merge(left, right):
    # Идём по обоим массивам сразу, каждый раз забирая меньший из головных элементов
    merged = []
    i, j = 0, 0
    while i < len(left) and j < len(right):
        # При равенстве берём элемент из левой части: этим и держится устойчивость
        if right[j] < left[i]:
            merged.append(right[j])
            j += 1
        else:
            merged.append(left[i])
            i += 1
    # Хвост, оставшийся от одного из массивов, дописываем целиком
    merged.extend(left[i:])
    merged.extend(right[j:])
    return merged


def merge_sort(nums):
    # Массив из одного элемента уже отсортирован: это базовый случай
    if len(nums) <= 1:
        return nums
    middle = len(nums) // 2
    left = merge_sort(nums[:middle])
    right = merge_sort(nums[middle:])
    return merge(left, right)

Сложность алгоритма

Сортировка слиянием даже в худшем случае работает за \(O(n \log n)\).

На каждом шаге прямого хода рекурсии массив разбивается на две примерно равные по размеру части, и разбиение продолжается до тех пор, пока длина массива не станет равной 1. Следовательно, каждый элемент, попадающий в такую цепочку, будет задействован примерно в \(\log_2 n\) вызовах рекурсивной функции.

Иначе можно сказать, что глубина рекурсии составляет \(O(\log n)\). Глубиной рекурсии называют максимальную глубину стека вызовов, достигаемую за время её работы.

На каждом шаге обратного хода рекурсии выполняется слияние двух отсортированных массивов, а оно выполняется одним проходом. Следовательно, на каждом уровне рекурсии затрачивается \(O(n)\) операций: сколько бы частей там ни было, вместе они содержат все \(n\) чисел, распределённых по ним при разбиении.

Общая сложность алгоритма \(O(n \log n)\).

Пространственная сложность алгоритма

Слияние собирает результат в новом массиве, куда копируются элементы объединяемых частей в правильном порядке. В приведённой реализации срезы и слитые списки создаются заново на каждом уровне, так что за время работы выделяется \(O(n\log{n})\) памяти.

Однако одновременно существуют только списки текущей ветви рекурсии: \(n/2 + n/4 + \ldots < n\) элементов и результат слияния, а списки уже завершённых ветвей освобождаются. Поэтому дополнительная память составляет \(O(n)\).

Устойчивость алгоритма

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

Быстрая сортировка

Быстрая сортировка (англ. quick sort) опирается на стратегию «разделяй и властвуй».

Стандартные библиотеки разных языков сделали разный выбор алгоритма сортировки: в распространённых реализациях C++ std::sort — интроспективная сортировка, то есть быстрая, переходящая в пирамидальную на неудачных входах (стандарт с C++11 требует лишь \(O(n \log n)\) сравнений), а в Python sorted() и list.sort() — Timsort, гибрид сортировки слиянием и вставками, устойчивый и использующий уже упорядоченные фрагменты: на упорядоченном входе он выполняет всего \(n - 1\) сравнений, а с версии 3.11 порядок слияний выбирается по правилу powersort. Автором быстрой сортировки был Чарльз Хоар, поэтому в честь него quick sort иногда называют сортировкой Хоара.

Принцип работы алгоритма

Любой алгоритм, построенный по этой стратегии, состоит из трёх шагов:

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

В merge sort шаг разделения прост, а шаг объединения нетривиален. В быстрой сортировке наоборот: разделение на части сложнее, зато части, отсортированные рекурсивно, объединяются дописыванием одного массива после другого.

• Возьмём исходный массив:

   [7  2  9  4  3  8  1]

• Выберем какое-нибудь число, например 4, и назовём его опорным. Все элементы, меньшие опоры, переложим в один массив, все большие — в другой, а саму опору (и равные ей) оставим посередине:

   [2  3  1]   4   [7  9  8]
    меньше   опора   больше

• Отсортируем каждую из частей рекурсивно.
• Соединим левую часть с правой.

Получен отсортированный массив:

   [1  2  3]   4   [7  8  9]   ──▶   [1  2  3  4  7  8  9]

Число, назначенное опорой, было выбрано произвольно.

Выбор опорного элемента

Если взять опорой максимум, разбиение выродится: слева окажется весь массив, справа пусто. Длина, уменьшенная всего на единицу, даст \(n\) уровней рекурсии, а работы на каждом линейно. Итого \(O(n^2)\), не лучше наивных квадратичных сортировок.

Следовательно, опора должна делить массив примерно пополам. Разумной эвристикой служит элемент, взятый из середины: на отсортированном или почти отсортированном массиве (а такие входы часты) он даёт ровное разбиение. Однако под любое простое фиксированное правило (первый или средний элемент, медиана трёх элементов) можно подобрать массив, вырождающий разбиение, и в олимпиадных тестах такие массивы появляются намеренно. Гарантию \(O(n \log n)\) даёт выбор опоры точной медианой, найденной за линейное время, однако константа такого алгоритма велика, и на практике выбирают случайную опору или интроспективную сортировку.

При опоре, выбранной случайно, плохое разбиение зависит не от массива, а от жребия. Гарантии это по-прежнему не даёт: при очень неудачной череде жребиев быстрая сортировка отработает за \(O(n^2)\). Однако вероятность такого исхода исчезающе мала, а в среднем получается \(O(n \log n)\).

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

import random


def partition(nums, pivot):
    # Раскладываем элементы по трём массивам, сравнивая каждый с опорой
    less, equal, greater = [], [], []
    for num in nums:
        if num < pivot:
            less.append(num)
        elif num > pivot:
            greater.append(num)
        else:
            equal.append(num)
    return less, equal, greater


def quick_sort(nums):
    # Массив из нуля или одного элемента уже отсортирован: это базовый случай
    if len(nums) <= 1:
        return nums
    # Опору выбираем случайно, чтобы входные данные не могли выродить разбиение
    pivot = random.choice(nums)
    less, equal, greater = partition(nums, pivot)
    return quick_sort(less) + equal + quick_sort(greater)

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

Сложность быстрой сортировки

Разбиение массива вокруг опоры выполняется одним проходом за \(O(n)\) операций. Если опора, выбираемая на каждом шаге, делит массив примерно пополам, уровней рекурсии будет \(O(\log n)\), и на каждом суммарно затрачивается \(O(n)\), откуда и получается \(O(n \log n)\) в среднем. При вырожденных разбиениях уровней становится \(n\), и сложность возрастает до \(O(n^2)\).

Схема с тремя новыми массивами стоит \(O(n)\) дополнительной памяти, и от этой платы на практике избавляются. Разбиение выполняют на месте: поддерживается граница «меньших», массив проходится одним проходом, и очередной элемент, меньший опоры, меняется местами с элементом на границе, а в конце опора ставится на место границы.

Памяти такой быстрой сортировке почти не требуется: сверх исходного массива расходуется только стек вызовов, \(O(\log n)\) при удачных разбиениях. Этим она и выигрывает у сортировки слиянием, требующей вспомогательный массив на \(n\) элементов.

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

Сортировка подсчётом

Отсортировать быстрее чем за \(O(n \log n)\) возможно, но лишь для узкого класса задач, устроенных особым образом.

Принцип работы алгоритма

Дан массив чисел:

nums = [5, 7, 1, 0, 1, 5, 11, 1]

Требуется отсортировать его по неубыванию. Известно, что числа в нём обозначают номера месяцев, то есть лежат в диапазоне от 0 до 11.

Заведём массив из 12 элементов, заполненный нулями.

months = [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0]

Теперь пройдём по массиву nums и для каждого числа увеличим на 1 счётчик, отвечающий этому месяцу:

months[5] += 1
months[7] += 1
months[1] += 1
months[0] += 1
months[1] += 1
months[5] += 1
months[11] += 1
months[1] += 1

Получим:

months = [1, 3, 0, 0, 0, 2, 0, 1, 0, 0, 0, 1]

Теперь пройдём по массиву months и допишем в nums столько копий каждого номера, сколько единиц накоплено в счётчике, отвечающем этому месяцу:

nums = []
for i in range(len(months)):
    for j in range(months[i]):
        nums.append(i)

Получим:

nums = [0, 1, 1, 1, 5, 5, 7, 11]

Код для случая, когда значения элементов лежат в полуинтервале от 0 до k:

def counting_sort(nums, k):
    # Создаём массив из k элементов, заполненный нулями
    counts = [0] * k
    # Проходим по массиву nums и увеличиваем соответствующий элемент в массиве counts
    for num in nums:
        counts[num] += 1
    # Проходим по массиву counts и добавляем в массив nums столько элементов, сколько встречается в counts
    nums = []
    for i in range(len(counts)):
        for j in range(counts[i]):
            nums.append(i)
    return nums

Алгоритм сортировки подсчётом использует \(O(k)\) дополнительной памяти на счётчики и \(O(n)\) на выходной массив, где \(k\) — длина диапазона значений, которые могут встретиться в массиве. Память, выделенная под вспомогательный массив, и есть плата за скорость. Чтобы создать этот массив, необходимо знать диапазон возможных значений. В примере потребовался дополнительный массив всего из 12 элементов.

Элементы здесь ни разу не сравниваются друг с другом, поэтому сортировка подсчётом и обходит границу \(O(n \log n)\), доказанную для сортировок сравнением: такая сортировка должна различить все \(n!\) перестановок входа, а каждое сравнение даёт не более одного бита информации, поэтому в худшем случае ей необходимо не менее \(\log_2(n!) \approx n \log_2 n - 1{,}44n\) сравнений, при \(n = 1000\) — около 8529. Работает она за \(O(n + k)\), и выигрыш сохраняется, только пока \(k\) сопоставимо с \(n\). Сортировать таким способом миллион чисел, разбросанных по диапазону до миллиарда, бессмысленно: массив, заведённый под счётчики, окажется в тысячу раз длиннее исходного.

Устойчивость алгоритма

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

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

Резюме

• Рекурсия складывается из базового случая, останавливающего спуск, и рекурсивного, сводящего задачу к меньшей; без базового случая происходит переполнение стека.
• Сортировка слиянием работает за \(O(n \log n)\) даже в худшем случае и устойчива, но требует \(O(n)\) дополнительной памяти под вспомогательный массив.
• Быстрая сортировка в среднем также \(O(n \log n)\) и почти не требует памяти, зато на неудачных разбиениях деградирует до \(O(n^2)\); разбиение на месте порядок равных элементов не сохраняет, а схема с тремя новыми массивами сохраняет ценой \(O(n)\) памяти.
• Опору в быстрой сортировке следует выбирать случайно: любое простое фиксированное правило можно обойти массивом, подобранным намеренно.
• Сортировка подсчётом не сравнивает элементы вовсе, благодаря чему обходит границу \(O(n \log n)\), но применима лишь на небольшом диапазоне значений и требует \(O(k)\) памяти на счётчики и \(O(n)\) на результат.
• Устойчивость является критерием выбора: она необходима всякий раз, когда данные сортируют несколько раз подряд по разным ключам.
• Собственную сортировку в рабочем коде писать незачем, потому что встроенная почти всегда быстрее и лучше отлажена; знать, как она устроена, необходимо, чтобы понимать, чего от неё ожидать.

Хеш-функции

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

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

В настоящей главе рассматривается, каким образом ключ преобразуется в номер корзины, почему различные ключи иногда попадают в одну корзину, как разрешаются столкновения ключей и за счёт чего словарь обеспечивает сложность \(O(1)\) в среднем.

Слайды к главе. Ассоциативный массив, хеш-таблица, коллизии, коэффициент заполнения и перехеширование, поисковый индекс изложены также в первой части лекции «Хеши, деревья и графы» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Понятие отображения

В интерфейсе массива, рассмотренном в главе про структуры данных, имеются две основные операции:

• get(index: int) -> value возвращает значение value из ячейки с индексом index;
• set(index: int, value: ValueType) записывает значение value в ячейку с индексом index.

Каждая из этих операций выполняется за \(O(1)\). Однако у массивов есть ограничение, накладываемое устройством памяти: в ячейках можно расположить объекты любого типа, а индексы могут быть только целыми числами.

В программе часто требуется получить объект не по порядковому номеру, а по другому признаку, например по названию, или, в терминологии программистов, получить значение (англ. value) по ключу (англ. key).

Пусть заданы множество городов и множество стран, причём одному городу отвечает единственная страна.

   города                страны
   ──────                ──────
   Новосибирск  ──┐
   Москва       ──┼───▶  Россия
   Казань       ──┘
   Минск        ─────▶   Беларусь
   Астана       ─────▶   Казахстан

Требуется написать программу-справочник, определяющую по городу страну. Если справочник будет пополняться, потребуется функция, добавляющая новую пару «город, страна».

Здесь город служит ключом, а страна — значением: каждому городу отвечает одна страна, а на страну может указывать любое количество городов.

Сопоставление, устроенное так, что каждому объекту первого множества (множество городов) отвечает единственный объект второго (множество стран), называется «отображением» (англ. map).

Отображение — другое название математического термина «функция», или «функциональная зависимость». Чаще всего функции отображают числа на оси X в числа на оси Y: для каждого числа из области определения можно выписать другое число — значение функции в этой точке.

Массивы также представляют собой частный случай отображения, сопоставляющий целому числу произвольное значение. Например, массив ["яблоко", "груша", "яблоко"] возвращает по числам 0 и 2 строку яблоко, а по числу 1 строку груша.

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

• get(key: KeyType) -> value возвращает значение value по ключу key;
• set(key: KeyType, value: ValueType) записывает значение value по ключу key.

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

Интерфейс, описывающий две этих операции, называют Map, а любую структуру, которая его реализует, называют «ассоциативным массивом» (англ. associative array).

Ассоциативные массивы

В большинстве языков программирования ассоциативные массивы встроены в язык.

Чаще всего их называют так же, как интерфейс, то есть Map, «отображение», или используют производные от слова «хеш-таблица»: Hash, HashMap, HashTable и даже просто Table. Эти названия подчёркивают способ реализации интерфейса отображения. Встречаются и другие: в Python ассоциативные массивы называют «словарями» (англ. dictionary).

Существует два распространённых способа реализовать (имплементировать) отображение в памяти: хеш-таблицы, которым посвящена настоящая глава, и деревья поиска, рассматриваемые в следующей. В некоторых языках имеются обе реализации: в Java это HashMap и TreeMap, а в C++ — std::unordered_map и std::map.

Во многих языках предусмотрен отдельный синтаксис для создания ассоциативного массива. В Python отображение реализовано типом dict, встроенным в интерпретатор.

Наивная реализация ассоциативного массива

Простейший способ реализовать ассоциативный массив — завести обыкновенный массив или список пар (key, value).

Для получения элемента по ключу осуществляется проход по всем элементам списка, находится пара с подходящим ключом и возвращается её значение. Для сохранения значения ищется пара с указанным ключом и изменяется хранимое в ней значение, а если пара не найдена, новая пара добавляется в конец массива.

class NaiveMap:
    def __init__(self):
        self.pairs = []

    def get(self, key):
        for stored_key, value in self.pairs:
            if stored_key == key:  # пара с указанным ключом найдена
                return value
        return None

    def set(self, key, value):
        for i, (stored_key, _) in enumerate(self.pairs):
            if stored_key == key:  # пара с указанным ключом найдена
                # обновить значение в найденной паре
                self.pairs[i] = (key, value)
                return
        # пара с заданным ключом не найдена
        self.pairs.append((key, value))

Такая реализация является медленной: на поиск элемента уходит в среднем \(O(n)\) операций.

Хеш-таблица и хеш-функция

Хеш-таблица (англ. hash table) — способ реализации ассоциативного массива, при котором данные хранятся в виде пар (key, value), разложенных по ячейкам обыкновенного массива. Эти ячейки называются корзинами (англ. bucket) и пронумерованы. Номер корзины зависит от ключа, поэтому можно ввести функцию, которая вычисляет этот номер непосредственно по ключу, без перебора.

Принцип работы хеш-функции и хеш-таблицы

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

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

Хеш-функцией (англ. hash function) называют функцию, преобразующую входные данные в целое число, причём для объектов разного типа применяются разные хеш-функции. Число, полученное на выходе, называется «хешем» или «хеш-суммой» (англ. hash, hash code или digest).

Пусть у каждой буквы алфавита есть индекс, равный её порядковому номеру. Хеш-функция может возвращать индекс первой буквы ключа. Тогда для яблока функция вернёт 33, для груши 4, а для сливы 19.

   ключ      первая буква   хеш
   ────      ────────────   ───
   яблоко         я          33
   груша          г           4
   слива          с          19

Поскольку хеш является целым числом, он пригоден на роль номера корзины без преобразований, необходимых в общем случае. Информация о грушах хранится в корзине 4: чтобы получить или обновить число груш на складе, достаточно обратиться к этой ячейке. Запоминать номера ячеек не требуется: хеш-функция вычислит их в любой момент.

   корзины
   ┌────┬───────────────────┐
   │  4 │ груша: 120 кг     │  ← сюда попадает «груша»
   ├────┼───────────────────┤
   │ 19 │ слива: 45 кг      │
   ├────┼───────────────────┤
   │ 33 │ яблоко: 300 кг    │
   └────┴───────────────────┘

Другой пример хеш-функции — сумма номеров всех букв названия. Тогда для «яблоко» она даст 92, для «груша» 70, а для «слива» 46.

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

Пусть корзин \( M = 11 \), а хеш вычисляется второй функцией — суммой номеров букв. Для «груши» она даёт 70, и остаток \( 70 \bmod 11 = 4 \):

   ключ  ──[хеш-функция]──▶  хеш  ──[% M]──▶  номер корзины  ──▶  значение
  «груша»                     70              70 % 11 = 4          120 кг

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

Отображение из ключа в значение разделилось на три независимых отображения. 1. Сначала хеш-функция отображает ключ в число, то есть в хеш. 2. Затем полученный хеш преобразуется в индекс корзины. 3. Наконец, в массиве корзин по индексу находится нужная корзина; в ней лежит значение.

Коллизии

Ситуация, при которой хеш-функция для разных входных данных возвращает одно и то же значение, называется «коллизией».

Например, и у «арбуза», и у «абрикоса» хеш, вычисленный по первой букве, равен 1, и оба ключа указывают на одну корзину.

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

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

В обоих случаях стоимость операции зависит от числа ключей, делящих одну корзину. Пока хеш-функция распределяет ключи равномерно, а корзин достаточно, цепочки остаются короткими, и поиск, вставка и удаление стоят в среднем \(O(1)\). Если же коллизий много, хеш-таблица вырождается в список пар, с которого начиналось рассмотрение, и поиск снова обходится в \(O(n)\).

Коэффициент заполнения и перехеширование

Условие «корзин достаточно» выражается числом. Отношение количества ключей в таблице к количеству корзин называют коэффициентом заполнения (англ. load factor): пока он мал, цепочки коротки и почти все корзины пусты. Если каждый из \(n\) ключей попадает в любую из \(M\) корзин с равной вероятностью, пустой остаётся доля корзин около \(e^{-n/M}\), а успешный поиск в методе цепочек просматривает в среднем \(1 + n/(2M)\) пар: сам ключ и половину остальных ключей его корзины. Даже при коэффициенте, равном единице, пустует примерно треть корзин, а на поиск уходит полтора сравнения, поэтому методу цепочек такое заполнение не страшно. При открытой адресации, напротив, с приближением коэффициента к единице число проб растёт неограниченно, и порог для неё выбирают заметно меньше единицы.

Как только коэффициент превышает порог, выбранный реализацией (в CPython у словаря это две трети, у множества — три пятых), заводится новый массив корзин, в несколько раз больший прежнего, и все ключи раскладываются по нему заново: номер корзины вычисляется по модулю \(M\), а \(M\) изменилось. Эту перестройку называют перехешированием (англ. rehashing).

Стоит она \(O(n)\), но происходит редко и с каждым разом всё реже, поскольку таблица растёт не на одну корзину, а кратно. Та же арифметика рассмотрена в главе «Основные структуры данных» под заголовком «Реаллокация в динамических массивах»: редкие дорогие перестройки, распределённые по множеству дешёвых операций, дают амортизированную \(O(1)\). В CPython 3.12 таблица словаря при перестройке растёт вдвое: перестройки происходят при добавлении 6-го, 11-го, 22-го, 43-го ключа и далее, когда заполнение таблицы из 8, 16, 32, 64 ячеек превышает две трети; таблица множества растёт вчетверо, пока в нём не больше 50 000 элементов.

Слайды к главе. Метод деления и число корзин, метод умножения, полиномиальный хеш строк, свойства хеш-функций, функция hash() и криптографические хеши изложены также во второй части лекции «Хеши, деревья и графы»; слайды лекции доступны на сайте книги и в PDF.

Выбор размера хеш-таблицы и вычисление номера корзины

Вычисление номера корзины методом деления

Простейший способ получить номер корзины \(\mathrm{bucket}(k)\) для целого ключа \(k\) — взять остаток от деления \(k\) на число корзин \(M\). Остаток от деления обозначается \(k \bmod M\) и произносится «\(k\) по модулю \(M\)». В языках программирования остаток вычисляется оператором %.

Любое целое число \(k\) может быть представлено в форме \(k = j\cdot M + r\), где все числа целые, а \(r \in[0,M)\). Число \(r\) и называется остатком.

Остатки от деления на \(M\) лежат в диапазоне от \(0\) до \((M-1)\) — это те же числа, что служат номерами корзин в хеш-таблице длины \(M\).

В разных языках программирования остаток от деления по-разному работает с отрицательными числами (см. подробности), не всегда так, как математическая операция взятия по модулю. Например, выражение \(-13 \bmod 5\) в одних языках даст \(2\), в других \(-3\). Если этого не учесть, можно получить отрицательный номер корзины.

Выбор числа корзин

Если номер корзины вычисляется методом деления, в качестве \(M\) лучше брать простое число, то есть делящееся без остатка только на себя и на 1.

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

Чем больше делителей у \(M\), тем чаще закономерности в ключах приводят к коллизиям; у простого числа делителей всего два, поэтому простое \(M\) уменьшает число столкновений. Например, номера пятого канала каждой платы из 64 каналов имеют вид \(64k + 5\): при \(M = 64\) все 1000 таких ключей попадают в одну корзину, при \(M = 1000\), имеющем с 64 общий делитель 8, — в 125 корзин, а при простом \(M = 1009\) занимают 1000 корзин, то есть коллизий нет вовсе.

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

Эта рекомендация относится к методу деления со слабой хеш-функцией. Распространённые реализации используют таблицы размером \(2^k\), у которых остаток вычисляется маской младших битов: словарь и множество CPython подмешивают старшие биты хеша при пробировании, HashMap в Java перемешивает хеш операцией h ^ (h >>> 16), а метод умножения, рассмотренный ниже, работает и при \(M = 2^k\).

Вычисление номера корзины методом умножения

Другой распространённый способ вычисления номера ячейки — метод умножения. Целое число обозначим на этот раз буквой \(h\), чтобы подчеркнуть, что это хеш ключа. Пусть количество корзин равно \(M\), а также зададим константу \(\alpha \in (0,1)\).

Тогда \(\mathrm{bucket}(h) = \left [ M \cdot \left \lbrace h \cdot \alpha \right \rbrace \right ]\) , где \(\left [ x \right ]\) обозначает целую часть числа \(x\), а \(\left \lbrace x \right \rbrace\) его дробную часть.

Алгоритм построения хеш-функции, опирающийся на метод умножения:

• Хеш ключа \(h\) домножается на выбранную константу \(\alpha\).
• От результата берётся дробная часть. Получается значение из диапазона \([0,1)\). Числа для разных ключей окажутся равномерно рассеяны.
• Полученное значение домножается на размер таблицы \(M\). Числа получаются распределёнными в диапазоне \([0, M)\)
• От результата берётся целая часть. С равными вероятностями получаются числа от \(0\) до \((M-1)\) — номера корзин. Равномерно заполняемые корзины дают меньше коллизий.

Дональд Кнут предложил брать в качестве \(\alpha\) число, обратное золотому сечению: последовательные ключи при этом рассеиваются по корзинам наиболее равномерно. $$ \displaystyle \alpha = \phi^{-1} = \left ( \frac{\sqrt 5 -1}{2} \right ) = 0.6180339887... $$

При любом \(\alpha\) дробные части чисел \(k\alpha\) для последовательных \(k\) делят отрезок \([0, 1)\) на промежутки не более трёх различных длин (теорема о трёх расстояниях); при \(\alpha = \phi^{-1}\) эти длины различаются меньше всего, а каждая следующая точка попадает в один из наибольших промежутков и делит его в золотом отношении.

Свойства хеш-функций

Не любая функция подходит на роль хеш-функции. Требуется функция, принимающая на вход данные и возвращающая число, отвечающее индексу корзины.

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

Например, пусть требуется выяснить стоимость товара в магазине. Если функция потратит на вычисление позиции элемента больше времени, чем ушло бы на перебор всех товаров на полках, применять её не имеет смысла.

Функция, преобразующая ключ в индекс корзины, должна обладать следующими свойствами:

• Детерминизм. Для одного и того же ключа функция всегда возвращает одинаковое значение. Если внутри используется случайное число, повторный вызов может вернуть новый индекс ячейки, и данные из хеш-таблицы окажутся недоступны. Например, взятие числа по модулю другого числа детерминировано: результат, вычисленный дважды, не изменится.
• Эффективность. Хеш-функция, вызываемая на каждой операции, должна вычисляться быстро. Сложность операции поиска складывается из сложности вычисления хеша и сложности поиска данных по хешу.
• Ограниченность. Результат функции должен принадлежать диапазону, задаваемому размером хеш-таблицы. Поэтому обычно сначала вычисляется хеш-функция, возвращающая произвольное число, а затем результат берётся по модулю \(M\), равного размеру хеш-таблицы. Тогда любой ключ окажется в интервале от \(0\) до \(M-1\), и обращения к индексу, не отвечающему ни одной из корзин, не произойдёт.
• Равномерность. Данные должны быть распределены по хеш-таблице равномерно, то есть каждое выходное значение равновероятно: при запуске функции для каждого элемента большого списка разных объектов получится примерно равное число ответов на каждое значение от \(0\) до \(M-1\). В противном случае в некоторые ячейки запись будет производиться чаще, чем в остальные, и обращение к таблице замедлится. Пример неравномерной функции — среднесуточная температура по городу и дате: большую часть времени она держится на одном уровне, а аномальные морозы или жара случаются редко.

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

• Лавинность. При незначительном изменении входных данных выходное значение должно меняться значительно. При хешировании паролей функция, лишённая лавинности, взламывается проще. Если злоумышленнику известно, что \(h(aa) = 22\), а \(h(bb) = 33\), то он может предположить такой \(password\), что \(h(password) = 44\). Перебрав небольшое число вариантов, он подберёт пароль по его хешу.
• Необратимость. Невозможно восстановить ключ по значению функции. Например, при регистрации на сайте к паролю пользователя применяется хеш-функция, и полученный хеш записывается в базу данных. Каждый раз, когда пароль вводится заново, к нему применяется та же функция, и новый хеш совпадёт с записью в базе, если введён исходный пароль. Даже получив доступ к базе, злоумышленник не должен иметь возможности восстановить пароль по украденным хешам.

Хеш-функция при этом не шифрует сообщения: зашифрованное сообщение расшифровывается обратно, а хеш необратим, и шифрование выполняют отдельные алгоритмы, например AES. Для контрольных сумм и проверки подлинности применяют SHA-256 и более новые функции: для MD5 и SHA-1, встречающихся в старых программах, построены коллизии (для SHA-1 — в 2017 году), и для защиты от подделки они непригодны.

Хранение паролей требует большего, чем однократное применение хеш-функции. Быструю криптографическую функцию злоумышленник, получивший базу, перебирает со скоростью миллиардов паролей в секунду, а одинаковые пароли дают одинаковые хеши. Поэтому к паролю перед хешированием приписывают случайную соль, хранимую рядом с хешем, и применяют намеренно медленную функцию: в стандартной библиотеке Python это hashlib.pbkdf2_hmac и hashlib.scrypt, а Argon2 и bcrypt доступны в пакетах argon2-cffi и bcrypt. Рекомендуемые параметры, например 600 000 итераций PBKDF2-HMAC-SHA256, сведены в OWASP Password Storage Cheat Sheet.

Построение хеш-функций для строк

Хеш-функции для строк вычисляются «полиномиальным хешированием» (от слова «полином», то есть многочлен). Хеш строки \(s\) вычисляется по формуле: $$ h(s)=\left(s_{1} q^{n-1}+s_{2} q^{n-2}+\cdots+s_{n-1} q+s_{n}\right) \bmod R $$ Здесь \(s_i\) обозначает код \(i\)-го символа (например, ASCII-код), \(n\) — длину строки, а \(R\) и \(q\) — выбранные константы.

Все вычисления производятся по модулю большого числа \(R\), поскольку для длинных строк сумма в скобках не помещается в целочисленный тип: в большинстве языков программирования произойдёт переполнение. В языках с «длинной арифметикой» переполнения не случится, однако с ростом чисел вычисления будут замедляться.

Выбор числа \(R\) зависит от типа переменной, отведённой под хеши. Например, для беззнаковых 4-байтовых целых чисел удобно выбрать \(R=2^{32}\), а для 8-байтовых можно взять \(R=2^{64}\).

Выбор величины \(q\) важен и для длинных строк. При \(R = 2^{32}\) чётное \(q\) обнуляет старшие степени, и хеш перестаёт зависеть от начала строки: при \(q = 256\) уже \(q^4 = 2^{32}\) обращается в ноль, остаются лишь четыре последних символа, и все десять тысяч имён файлов от run_0000.dat до run_9999.dat получают один и тот же хеш. Поэтому \(q\) берут нечётным, а ради универсальности — большим простым числом.

Номер корзины получается как остаток от деления хеша на число корзин. Чем меньше общих делителей у \(q\), \(M\) и \(R\), тем реже коллизии. В качестве \(R\) выше было условлено использовать \(2^{32}\), поэтому любое нечётное число взаимно просто с \(R\).

Число \(M\) меняется вслед за размером хеш-таблицы, ещё не известным в момент вычисления хеша, поэтому нельзя гарантировать, что заданное заранее \(q\) и число корзин \(M\) окажутся взаимно простыми. Однако большое простое \(q\) делает нетривиальные общие делители маловероятными, поскольку у простого числа нет делителей, кроме него самого и единицы. \(M\) обычно также выбирают простым, поэтому общие делители появятся, только когда \(M=q\).

Реализация хеш-таблицы на цепочках

Возьмём одиннадцать корзин — число простое и небольшое, чтобы коллизии были заметны, — а хеш будем вычислять суммой номеров букв, как в примере со складом:

ALPHABET = 'абвгдеёжзийклмнопрстуфхцчшщъыьэюя'


def letters_hash(key):
    # Хеш — сумма номеров букв, входящих в ключ
    return sum(ALPHABET.index(letter) + 1 for letter in key)


class HashMap:
    def __init__(self, buckets_count=11):
        # В каждой корзине лежит список пар: это и есть метод цепочек
        self.buckets = [[] for _ in range(buckets_count)]

    def _bucket(self, key):
        # Хеш превращается в номер корзины остатком от деления
        return self.buckets[letters_hash(key) % len(self.buckets)]

    def get(self, key):
        # Перебираем цепочку, привязанную к корзине, а не всю таблицу
        for stored_key, value in self._bucket(key):
            if stored_key == key:
                return value
        return None

    def set(self, key, value):
        bucket = self._bucket(key)
        for i, (stored_key, _) in enumerate(bucket):
            if stored_key == key:
                bucket[i] = (key, value)
                return
        bucket.append((key, value))

У «груши» сумма номеров букв равна 70, и остаток \( 70 \bmod 11 = 4 \), а у «яблока» сумма 92, и остаток \( 92 \bmod 11 = 4 \) — тот же. Это коллизия: два ключа делят одну корзину и хранятся в ней списком:

warehouse = HashMap()
warehouse.set('груша', 120)
warehouse.set('яблоко', 300)

print(letters_hash('груша') % 11)   # 4
print(letters_hash('яблоко') % 11)  # 4
print(warehouse.buckets[4])         # [('груша', 120), ('яблоко', 300)]
print(warehouse.get('яблоко'))      # 300

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

bucket_index = hash('груша') % 11

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

Функция hash устроена по-разному для разных типов. Хеш целого числа соли не содержит и равен самому числу, взятому по модулю простого числа \(2^{61} - 1\): hash(42) равно 42, hash(2**61) — единице, а hash(-1) равно −2, поскольку значение −1 в C-интерфейсе интерпретатора обозначает ошибку. Строки и байты хешируются функцией SipHash со случайной солью (PEP 456); начиная с Python 3.11 по умолчанию применяется вариант SipHash-1-3, до этого — SipHash-2-4, что показывает sys.hash_info.algorithm. Переменная окружения PYTHONHASHSEED позволяет зафиксировать соль, например для воспроизведения ошибки. Из-за соли порядок обхода множества строк меняется от запуска к запуску, и алгоритм, выбирающий первый из равных при переборе такого множества, недетерминирован; словарь же начиная с Python 3.7 гарантированно хранит порядок вставки.

Ключом словаря и элементом множества может служить только хешируемый объект, хеш которого не меняется за время его жизни. Изменяемые контейнеры list, dict и set не хешируются: изменение списка, уже лежащего ключом в словаре, изменило бы его хеш, и ключ стал бы ненаходимым, поэтому hash([1, 2]) возбуждает TypeError. Хешируемость при этом не совпадает с неизменяемостью: кортеж хешируется, только если хешируемы все его элементы, а экземпляры собственных классов по умолчанию хешируются по идентичности, хотя их атрибуты можно менять.

Поисковый индекс

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

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

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

Отображение, которое ставит каждому объекту в соответствие его расположение, называют «поисковым индексом».

Хеш-таблица должна находить позиции любой подстроки, а значит, в неё необходимо заранее добавить все подстроки текста. Если подстроки в таблице нет, нет её и в тексте.

Позиция при этом получается сразу, однако такой способ расточителен по памяти. Подстрок в тексте столько, сколько способов выбрать две границы: \(N\cdot(N+1)/2\), где \(N\) — длина текста. Следовательно, в хеш-таблицу требуется добавить \(O(N^2)\) пар (key, value). Поскольку ключами служат сами подстроки, каждая пара займёт в среднем \(O(N)\) памяти, а всего — \(O(N^3)\).

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

На практике индексируют не все подстроки, а слова, разделённые пробелами. Текст разбивается на слова, и в хеш-таблицу помещаются пары из слова и списка его позиций. Таких пар \(O(N)\), памяти требуется линейное количество, а поиск по целому слову остаётся мгновенным. Так устроены поисковые системы и полнотекстовый поиск в базах данных, только вместо списка позиций там хранятся более сложные структуры.

Резюме

• Хеш-таблица превращает поиск по ключу в вычисление: хеш-функция вычисляет по ключу число, остаток от деления этого числа на количество корзин даёт номер ячейки, а далее работает обычный массив.
• Коллизии неизбежны у любой хеш-функции, и разрешаются они либо методом цепочек, когда в корзине хранится список пар, либо открытой адресацией, когда пара помещается в ближайшую свободную ячейку.
• Ожидаемая \(O(1)\) обеспечивается двумя условиями: хеш-функция распределяет ключи равномерно, а корзин достаточно. Второе обеспечивается перехешированием, стоящим \(O(n)\) на редких перестройках и потому не ухудшающим среднюю стоимость.
• От хеш-функции требуются детерминизм, эффективность, ограниченность и равномерность, а от криптографической — дополнительно лавинность и необратимость.
• Если номер корзины вычисляется остатком от деления, число корзин выбирают простым, чтобы закономерности, скрытые во входных ключах, не приводили раз за разом в одну ячейку; реализации с размером таблицы \(2^k\), например словарь CPython, перемешивают биты хеша.
• Строки хешируются полиномиально по модулю большого числа \(R\); основание \(q\) выбирают нечётным, то есть взаимно простым с \(R = 2^{32}\), а ради универсальности — большим простым.
• Поисковый индекс представляет собой ту же хеш-таблицу, где ключом служит слово, а значением — список его позиций; на нём основан и полнотекстовый поиск в базах данных.

Деревья

В массиве, связном списке, стеке и очереди элементы выстроены друг за другом. Однако файловая система на диске, структура HDF5-файла с результатами измерений, иерархия объёмов детектора в Geant4, дерево вызовов, собранное профилировщиком, устроены как иерархии. Для их описания существует отдельная структура данных — дерево.

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

Слайды к главе. Определения, двоичное дерево и класс Node, обходы в глубину и в ширину, k-d дерево и октодерево изложены также в третьей части лекции «Хеши, деревья и графы» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Понятие дерева

Деревом называют набор узлов (вершин), соединённых рёбрами, в котором выполнены три условия:

• есть один выделенный узел, корень (англ. root);
• у каждого узла, кроме корня, в точности один родитель (англ. parent);
• от корня до любого узла можно дойти по рёбрам, причём единственным способом, ведущим туда.

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

Основная терминология:

• потомками (детьми) узла называют узлы, которым он приходится родителем;
• листом (англ. leaf) называется узел без потомков;
• внутренний узел имеет хотя бы одного потомка;
• поддерево составляют узел вместе со всеми его потомками, потомками потомков и так далее; каждый узел можно считать корнем собственного поддерева, подвешенного под ним;
• глубина узла равна числу рёбер, пройденных на пути от корня до узла (у корня глубина 0);
• уровень объединяет узлы одной глубины;
• высота дерева равна наибольшей глубине, найденной среди всех узлов.

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

Главным свойством дерева является рекурсивность. Дерево складывается из корня и поддеревьев, каждое из которых само является деревом. Поэтому почти все алгоритмы для деревьев записываются рекурсивно и сводятся к тому, чтобы обработать корень, а затем рекурсивно обработать его поддеревья. Базовый случай — пустое дерево.

Двоичные деревья и класс Node

Двоичным (бинарным) деревом называют дерево, в котором у каждого узла не больше двух потомков, различаемых как левый и правый. На двоичных деревьях построены деревья поиска и кучи, а любое дерево общего вида сводится к двоичному.

В Python узел дерева описывается классом со ссылками на потомков, как элемент связного списка, только ссылок теперь две:

class Node:
    def __init__(self, value, left=None, right=None):
        self.value = value  # данные, хранящиеся в узле
        self.left = left    # ссылка на левого потомка (или None)
        self.right = right  # ссылка на правого потомка (или None)

Соберём дерево из пяти узлов:

      5
     / \
    3   8
   / \
  1   4

root = Node(5, Node(3, Node(1), Node(4)), Node(8))

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

Обходы дерева

Обойти дерево значит побывать в каждом узле по одному разу. В отличие от массива, у дерева есть несколько естественных порядков обхода. Они делятся на два семейства: обходы в глубину (DFS, англ. depth-first search), уходящие вниз по ветви, и обход в ширину (BFS, англ. breadth-first search), идущий по уровням.

Обходы в глубину

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

def preorder(root):        # корень -> левое -> правое
    if root is None:
        return
    print(root.value)      # обрабатываем узел до потомков
    preorder(root.left)
    preorder(root.right)


def inorder(root):         # левое -> корень -> правое
    if root is None:
        return
    inorder(root.left)
    print(root.value)      # обрабатываем узел между потомками
    inorder(root.right)


def postorder(root):       # левое -> правое -> корень
    if root is None:
        return
    postorder(root.left)
    postorder(root.right)
    print(root.value)      # обрабатываем узел после потомков

Для дерева, изображённого выше, preorder выведет 5 3 1 4 8, inorder выдаст 1 3 4 5 8, а postorder даст порядок 1 4 3 8 5.

Pre-order подходит для копирования и сериализации сверху вниз: сначала создаётся узел, затем его потомки. Post-order применяется для удаления и для вычислений снизу вверх, когда результат в узле зависит от значений, вычисленных в поддеревьях; так находят высоту, размер поддеревьев, значение арифметического выражения, разобранного в дерево. In-order выдаёт элементы дерева поиска в отсортированном порядке.

Обход в ширину

Обход в ширину идёт по уровням: сначала корень, затем все узлы глубины 1, затем глубины 2 и так далее. Естественной реализацией служит очередь из главы о базовых структурах; рекурсивная запись тоже возможна — обходом в глубину, раскладывающим узлы по спискам уровней, — но очередь проще:

from collections import deque


def level_order(root):
    if root is None:
        return
    queue = deque([root])
    while queue:
        node = queue.popleft()      # берём узел из начала очереди
        print(node.value)
        if node.left:               # и ставим его потомков в конец
            queue.append(node.left)
        if node.right:
            queue.append(node.right)

Для того же дерева получится 5 3 8 1 4, по уровням. Любой обход посещает каждый узел по одному разу (обход в глубину вдобавок проходит по каждому ребру дважды, вниз и обратно), поэтому все они работают за \( O(n) \), где \( n \) — число узлов. Дополнительной памяти требуется \( O(h) \) на стек рекурсии у DFS (где \( h \) — высота дерева) и до \( O(n) \) на очередь у BFS, вмещающую самый широкий уровень.

Слайды к главе. Поиск, вставка и удаление в дереве поиска, высота и сбалансированность, число деревьев поиска изложены также в четвёртой части лекции «Хеши, деревья и графы»; слайды лекции доступны на сайте книги и в PDF.

Двоичное дерево поиска

Двоичным деревом поиска (англ. binary search tree, BST) называют двоичное дерево, в каждом узле которого выполняется свойство порядка: все значения в левом поддереве строго меньше значения узла, а все значения в правом строго больше.

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

def find(root, key):
    while root is not None and root.value != key:
        root = root.left if key < root.value else root.right
    return root  # узел с ключом key или None, если ключа нет

При вставке спуск выполняется так же, как при поиске, а новый узел подвешивается там, где спуск достиг None:

def insert(root, key):
    if root is None:
        return Node(key)          # нашли свободное место
    if key < root.value:
        root.left = insert(root.left, key)
    elif key > root.value:
        root.right = insert(root.right, key)
    return root                   # корень поддерева; равный ключ не вставляется

Поиск, вставка и удаление стоят \( O(h) \), поскольку проходят один путь от корня вниз. In-order-обход дерева поиска выдаёт ключи по возрастанию: сначала всё меньшее (левое поддерево), затем узел, затем всё большее. Получается структура, обеспечивающая одновременно быстрый поиск, вставку, удаление и перебор по порядку. Ни отсортированный массив с его медленной вставкой, ни хеш-таблица, лишённая порядка, этого не обеспечивают.

Сбалансированность

Эффективность BST определяется высотой \( h \), задающей цену любой операции. Если вставлять ключи в случайном порядке, высота растёт как \( O(\log n) \), хотя и с множителем больше единицы. Средняя глубина узла близка к \( 2 \ln n \approx 1{,}39 \log_2 n \), а высота, согласно работам Л. Девруа и Б. Рида, растёт как \( 4{,}311 \ln n - 1{,}953 \ln \ln n \), то есть асимптотически примерно как \( 3 \log_2 n \); при \( n = 10^5 \) высота случайного дерева составляет около \( 2{,}4 \log_2 n \). Но если вставить ключи 1, 2, 3, ..., n по порядку, каждый новый узел уйдёт направо, и дерево выродится в цепочку высоты \( n - 1 \). Все операции станут линейными, а рекурсивная вставка из листинга выше на таком входе исчерпает предел глубины рекурсии Python уже на тысяче ключей; для вырожденных деревьев вставку записывают циклом.

Дерево называется сбалансированным, если его высота составляет \( h = O(\log n) \), а значит, все операции работают за \( O(\log n) \). Строгий вариант — условие АВЛ-дерева: у каждого узла высоты левого и правого поддеревьев отличаются не больше чем на единицу, что даёт \( h < 1{,}44 \log_2(n + 2) \); красно-чёрное дерево поддерживает более слабое условие и гарантирует \( h \le 2 \log_2(n + 1) \).

Сохранять сбалансированность при любых вставках и удалениях позволяют самобалансирующиеся деревья (АВЛ-дерево, красно-чёрное дерево), выполняющие после каждой операции небольшие локальные перестройки, называемые поворотами. На красно-чёрных деревьях построены TreeMap в Java и std::map в распространённых реализациях C++, упомянутые в главе про хеш-таблицы; к сбалансированным относятся и B-деревья индексов баз данных, рассмотренные в главе «Базы данных». В стандартной библиотеке Python дерева поиска нет, поскольку обычно достаточно dict, set и модуля bisect для отсортированного списка.

Слайды к главе. Куча в массиве, приоритетная очередь и модуль heapq, пирамидальная сортировка изложены также в пятой части лекции «Хеши, деревья и графы»; слайды лекции доступны на сайте книги и в PDF.

Куча

Куча (англ. heap) представляет собой структуру данных для задач, в которых требуется быстро находить максимум (или минимум) в наборе элементов, меняющемся в процессе работы. В невозрастающей куче (max-heap) выполняется основное свойство кучи: значение любого узла не меньше значений его потомков. Следовательно, в корне всегда находится максимум. В min-heap наоборот, в корне минимум.

В отличие от дерева поиска, куча не упорядочивает элементы полностью: между левым и правым поддеревьями никакого порядка нет. Взамен куча всегда остаётся почти полным двоичным деревом. Все уровни, кроме последнего, заполнены целиком, а последний заполняется слева направо по мере роста. Такое дерево не бывает вырожденным, и его высота всегда \( O(\log n) \).

Куча в массиве

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

Куча:                Массив:

      9              [9, 7, 8, 3, 1, 4]
     / \              0  1  2  3  4  5
    7   8
   / \  /
  3  1 4

У узла с индексом \( i \) потомки лежат в ячейках \( 2i + 1 \) и \( 2i + 2 \), а родитель в ячейке \( \lfloor (i-1)/2 \rfloor \). Классы и указатели не требуются: любой массив чисел уже представляет собой дерево, разложенное по уровням.

Куча основана на двух операциях, называемых просеиванием:

• просеивание вверх (sift up): элемент, дописанный в конец массива, меняется местами с родителем, пока он больше родителя;
• просеивание вниз (sift down): корень, ставший меньше потомков, меняется местами с бóльшим из них и опускается, пока свойство кучи не восстановится.

Оба просеивания проходят не больше одного пути от корня до листа, то есть стоят \( O(\log n) \). На них строится приоритетная очередь: добавление элемента за \( O(\log n) \), просмотр максимума за \( O(1) \), извлечение максимума (последний элемент переставляется в корень и просеивается вниз) за \( O(\log n) \).

В Python куча реализована модулем heapq как min-heap над обычным списком, передаваемым в функции модуля; начиная с Python 3.14 модуль содержит и функции для max-heap (heappush_max, heappop_max и другие):

import heapq

distances = [5.2, 1.1, 3.7, 0.4]
heapq.heapify(distances)          # превращает список в кучу за O(n)
heapq.heappush(distances, 2.6)    # добавление за O(log n)
print(heapq.heappop(distances))   # 0.4 — минимум, за O(log n)

Функция heapify строит кучу за \( O(n) \), а не за \( O(n \log n) \): внутренние узлы просеиваются вниз начиная с последнего, и большинство из них, лежащих у самого дна, опускается лишь на один-два уровня. Функции heapq.nlargest и heapq.nsmallest отбирают \( k \) наибольших или наименьших элементов из \( n \), поддерживая кучу из \( k \) элементов, за \( O(n \log k) \) времени и \( O(k) \) памяти: так из миллиона событий выбирают десять самых энергичных без сортировки всего набора.

Если требуется max-heap, в версиях Python до 3.13 включительно в куче хранят элементы с обратным знаком. Этот приём применяется в следующей главе, в алгоритме, строящем остовное дерево.

Пирамидальная сортировка

Куча даёт ещё один способ сортировать за \( O(n \log n) \), пирамидальную сортировку (англ. heap sort). Она состоит из двух этапов:

1. Превратить массив в max-heap, просеяв вниз все внутренние узлы, начиная с последнего и заканчивая корнем.
2. Повторять \( n - 1 \) раз: обменять корень (текущий максимум) с последним элементом ещё не отсортированной части и просеять новый корень вниз. Снятые максимумы один за другим встают в конец массива на окончательные места.

Дополнительной памяти heap sort, в отличие от сортировки слиянием, не требует: всё происходит в исходном массиве. Неудачных входов у него, в отличие от быстрой сортировки, не бывает: любой массив обрабатывается за \( O(n \log n) \). Платой являются неустойчивость и большая константа: просеивание обращается к далеко отстоящим ячейкам массива, кеш процессора работает хуже, и на практике heap sort обычно заметно медленнее quick sort. Полная реализация рассматривается ниже в задачах.

Деревья в физических задачах

Ниже приведены три типичных сюжета из вычислительной физики.

Поиск соседей и k-d деревья. В молекулярной динамике, методе SPH или при кластеризации точек, измеренных в эксперименте, постоянно требуется выяснять, какие частицы находятся рядом с выбранной. Перебор всех пар стоит \( O(N^2) \). k-d дерево (k-dimensional tree) рекурсивно делит пространство плоскостями пополам, и запрос ближайших соседей точки выполняется в среднем за \( O(\log N) \), если размерность пространства мала, как у координат частиц; при десятках измерений k-d дерево почти не выигрывает у перебора. В SciPy оно уже реализовано:

import numpy as np
from scipy.spatial import KDTree

points = np.random.default_rng(0).random((100_000, 3))  # частицы в кубе
tree = KDTree(points)                    # построение за O(N log N)

dist, idx = tree.query(points[0], k=10)          # 10 ближайших соседей
neighbors = tree.query_ball_point(points[0], r=0.05)  # все соседи в радиусе

Гравитационная задача N тел и октодеревья. Прямое суммирование сил между \( N \) телами требует \( O(N^2) \) операций на шаг, что для галактики из миллиардов звёзд неприемлемо. Алгоритм Барнса — Хата строит октодерево (англ. octree): куб пространства, вмещающий всю систему, рекурсивно делится на 8 октантов, пока в каждом листе не останется по частице. Для далёкой группы частиц незачем суммировать вклады по одной, достаточно слагаемого от её суммарной массы, приложенной в центре масс и записанной в узле дерева. Критерий: если угловой размер ячейки \( s/d \) меньше порога \( \theta \), ячейка не раскрывается. Сложность снижается до \( O(N \log N) \), и такие деревья вместе с более сложным быстрым мультипольным методом работают внутри современных астрофизических кодов наподобие GADGET.

Иерархические данные. Формат HDF5, стандарт де-факто для больших численных данных, устроен как дерево: группы содержат подгруппы и датасеты, как каталоги и файлы (строго говоря, как корневой ориентированный граф: жёсткие ссылки позволяют включить один объект в несколько групп). Деревом являются и геометрия детектора в Geant4 из объёмов, вложенных в объёмы, и символьное выражение в SymPy, где узлами служат операции, а листьями — переменные и константы. Иерархия почти наверняка означает, что в основе лежат дерево и рекурсивные обходы.

Разбор задач

Во всех задачах, где на вход подаётся корень, используется класс Node, описанный выше. Каждую задачу рекомендуется сначала решить самостоятельно; все они собраны в тренажёре.

Задача 1. Максимальная глубина

Условие. Дан корень двоичного дерева. Требуется найти его максимальную глубину, то есть наибольшее число узлов, лежащих на пути от корня до листа (включая корень и лист).

Идея решения. Глубина дерева равна глубине более глубокого из поддеревьев плюс единица за сам корень. Базовый случай — пустое дерево глубины 0.

def max_depth(root):
    # Базовый случай: пустое дерево не добавляет к глубине ничего
    if root is None:
        return 0
    # Более глубокое из поддеревьев плюс сам корень
    return 1 + max(max_depth(root.left), max_depth(root.right))

Сложность. По времени \( O(n) \), так как каждый узел посещается один раз. По памяти \( O(h) \) на стек рекурсии, где \( h \) — высота дерева.

Задача 2. Сбалансированное дерево

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

Идея решения. Прямолинейное решение: в каждом узле сравнивать высоты поддеревьев, вычисленные функцией из предыдущей задачи. Но тогда высота каждого узла будет вычисляться заново на каждом уровне выше него, и в худшем случае получится \( O(n^2) \).

Лучше совместить оба вычисления в одном обходе. Пусть функция возвращает высоту поддерева, а для несбалансированного поддерева значение-сигнал -1, немедленно передаваемое наверх без дальнейших проверок.

def check_height(root):
    """Высота поддерева или -1, если оно несбалансировано."""
    if root is None:
        return 0

    left = check_height(root.left)
    if left == -1:                 # слева уже нашли дисбаланс
        return -1

    right = check_height(root.right)
    if right == -1:                # справа уже нашли дисбаланс
        return -1

    if abs(left - right) > 1:      # дисбаланс в текущем узле
        return -1

    return 1 + max(left, right)


def is_balanced(root):
    return check_height(root) != -1

Сложность. По времени \( O(n) \): один post-order-обход, высота каждого узла вычисляется однократно. По памяти \( O(h) \) на стек рекурсии.

Задача 3. Дерево поиска

Условие. Требуется проверить, является ли двоичное дерево деревом поиска: значения, лежащие в левом поддереве каждого узла, строго меньше значения узла, а в правом строго больше.

Идея решения. Частая ошибка — проверять только соседние узлы: left.value < node.value < right.value. Этого недостаточно:

Дерево поиска:        Не дерево поиска:
      5                     5
     / \                   / \
    3   8                 3   8
   / \                   / \
  1   4                 1   6

В правом дереве узел 6 больше своего родителя 3, и локально условие выполнено. Однако 6 находится в левом поддереве корня 5, а значит, обязан быть меньше 5. Условие является глобальным: каждый узел ограничен всеми своими предками.

Будем спускаться по дереву и передавать вниз интервал разрешённых узлу значений \( (\text{low}, \text{high}) \). При переходе налево ужесточается верхняя граница значением узла, при переходе направо — нижняя.

def is_bst(root, low=float('-inf'), high=float('inf')):
    if root is None:
        return True
    # Значение узла обязано лежать строго внутри интервала предков
    if not (low < root.value < high):
        return False
    return (is_bst(root.left, low, root.value)      # слева всё < root.value
            and is_bst(root.right, root.value, high))  # справа всё > root.value

Альтернатива: выполнить in-order-обход и проверить, что выданные им значения идут строго по возрастанию. Для дерева поиска это является критерием.

Сложность. По времени \( O(n) \), по памяти \( O(h) \) на стек рекурсии.

Задача 4. Сколько существует деревьев поиска

Условие. Требуется определить, сколько различных двоичных деревьев поиска можно построить из всех чисел от 1 до \( n \). Число \( n \) не превосходит 20.

Идея решения. Выберем корнем число \( k \). Тогда числа \( 1, \dots, k-1 \) обязаны попасть в левое поддерево, а \( k+1, \dots, n \) в правое, причём каждое из поддеревьев само является деревом поиска. Число деревьев из \( m \) последовательных чисел зависит только от \( m \), поэтому получаем рекуррентность

\[ C_n = \sum_{k=1}^{n} C_{k-1} C_{n-k}, \qquad C_0 = 1. \]

Это числа Каталана, которые также считают правильные скобочные последовательности и блуждания из \( 2n \) шагов \( \pm 1 \), которые не опускаются ниже нуля и заканчиваются в нуле (пути Дика); без условия возврата в ноль получилось бы другое число, \( \binom{2n}{n} \). Для них известна замкнутая формула

\[ C_n = \frac{1}{n+1} \binom{2n}{n} = \frac{(2n)!}{n! (n+1)!}. \]

from math import comb


def count_bst(n):
    # Число Каталана: C(2n, n) / (n + 1), деление всегда нацело
    return comb(2 * n, n) // (n + 1)

Если формула неизвестна, ответ вычисляется по рекуррентности динамическим программированием:

def count_bst_dp(n):
    counts = [1] + [0] * n           # counts[0] = 1: пустое дерево одно
    for size in range(1, n + 1):
        for root in range(1, size + 1):
            # root - 1 чисел уходит налево, size - root — направо
            counts[size] += counts[root - 1] * counts[size - root]
    return counts[n]

Вычисления необходимо вести в целых числах. Наивное fac(2*n) / (fac(n) * fac(n+1)) возвращает float с 53 битами мантиссы, хотя частное двух целых Python вычисляет точно и округляет один раз. Пока \( C_n < 2^{53} \), то есть до \( n = 30 \), округление даёт точное значение, а \( C_{31} > 2^{53} \) в float уже не представимо, и наивная формула занижает его на единицу. Если же перевести факториалы во float до деления, как в языках без длинной арифметики, ошибки округления вносят перевод \( 40! \approx 8{,}16 \cdot 10^{47} \), умножение и деление, и ответ неверен уже при \( n = 20 \), внутри условия задачи: получается 6564120419.999999, и int даёт 6564120419 вместо 6564120420. Целочисленный вариант ничем не сложнее.

Сложность. Формула с биномиальным коэффициентом требует \( O(n) \) умножений; вариант с динамическим программированием обходится в \( O(n^2) \) операций и \( O(n) \) памяти.

Задача 5. Удаление узла из дерева поиска

Условие. Дано дерево поиска с уникальными целыми ключами. Требуется удалить узел с заданным ключом так, чтобы дерево осталось корректным деревом поиска, и вернуть корень изменённого дерева. Если ключа нет, дерево возвращается нетронутым. Создавать новые узлы нельзя, сложность должна быть \( O(h) \).

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

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

def remove(root, key):
    if root is None:                     # ключа в дереве нет
        return None

    if key < root.value:                 # ищем слева
        root.left = remove(root.left, key)
    elif key > root.value:               # ищем справа
        root.right = remove(root.right, key)
    else:                                # нашли узел с ключом key
        if root.left is None:            # случаи 1 и 2: нет левого потомка
            return root.right
        if root.right is None:           # случай 2: нет правого потомка
            return root.left

        # Случай 3: ищем преемника — минимум правого поддерева
        parent, succ = root, root.right
        while succ.left is not None:
            parent, succ = succ, succ.left

        # Вырезаем преемника со старого места...
        if parent.left is succ:
            parent.left = succ.right
        else:
            parent.right = succ.right

        # ...и ставим его на место удаляемого узла
        succ.left = root.left
        succ.right = root.right
        return succ

    return root

Сложность. По времени \( O(h) \), поскольку спуск к узлу и спуск к преемнику вместе образуют один путь от корня вниз. По памяти \( O(h) \) на рекурсию поиска (её несложно переписать циклом до \( O(1) \)).

Задача 6. Пирамидальная сортировка

Условие. По результатам соревнования дан список участников: логин, число решённых задач \( P \) и штраф \( F \). Требуется отсортировать таблицу: выше стоит участник, у которого больше решённых задач; при равенстве тот, у кого меньше штраф; если и штрафы равны, тот, чей логин идёт раньше по алфавиту. Кучу необходимо реализовать самостоятельно, встроенными сортировками и heapq пользоваться нельзя.

Ввод:                  Вывод:
5                      gena
alla 4 100             timofey
gena 6 1000            alla
gosha 2 90             gosha
rita 2 90              rita
timofey 4 80

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

def sort_key(user):
    login, solved, penalty = user
    return (-solved, penalty, login)

Остаётся отсортировать массив по этому ключу пирамидальной сортировкой. Строим max-heap в исходном массиве, затем раз за разом переставляем максимум, то есть худшего из оставшихся участников, в конец неотсортированной части:

def sift_down(items, start, end):
    """Просеивает элемент start вниз внутри items[start:end + 1]."""
    root = start
    while True:
        child = 2 * root + 1               # левый потомок
        if child > end:                    # потомков нет — дно кучи
            break
        # Из двух потомков выбираем большего
        if child + 1 <= end and sort_key(items[child]) < sort_key(items[child + 1]):
            child += 1
        if sort_key(items[root]) < sort_key(items[child]):
            items[root], items[child] = items[child], items[root]
            root = child                   # спускаемся за элементом дальше
        else:
            break                          # свойство кучи восстановлено


def heap_sort(items):
    n = len(items)
    # Этап 1: строим кучу — просеиваем все внутренние узлы справа налево
    for start in range((n - 2) // 2, -1, -1):
        sift_down(items, start, n - 1)
    # Этап 2: снимаем максимум с вершины кучи в конец массива
    for end in range(n - 1, 0, -1):
        items[0], items[end] = items[end], items[0]
        sift_down(items, 0, end - 1)


def main():
    n = int(input())
    users = []
    for _ in range(n):
        login, solved, penalty = input().split()
        users.append((login, int(solved), int(penalty)))

    heap_sort(users)

    print('\n'.join(user[0] for user in users))


if __name__ == '__main__':
    main()

После этапа 1 худший по ключу участник стоит в корне кучи, в ячейке 0. Обмен с последним элементом ставит его на окончательное место, а однократное просеивание вниз восстанавливает кучу в укоротившейся части массива. В итоге массив отсортирован по возрастанию ключа, и лучшие участники стоят в начале.

Сложность. Построение кучи занимает \( O(n) \), поскольку низкие узлы просеиваются на малую глубину, а затем выполняются \( n - 1 \) просеиваний по \( O(\log n) \). Итого \( O(n \log n) \) по времени в худшем случае и \( O(1) \) дополнительной памяти: сортировка выполняется на месте. В рабочем коде достаточно sorted(users, key=sort_key).

Резюме

• Дерево является рекурсивной структурой из корня и поддеревьев, каждое из которых само дерево. Базовый случай алгоритмов для него — пустое дерево None.
• Обходы в глубину (pre-, in-, post-order) записываются рекурсией, обход в ширину — очередью, в которой лежат узлы текущего и следующего уровней; все стоят \( O(n) \).
• Дерево поиска обеспечивает поиск, вставку и удаление за \( O(h) \); чтобы высота \( h \) была \( O(\log n) \), дерево должно быть сбалансированным.
• Куча укладывается в массив как почти полное дерево, отдаёт максимум за \( O(1) \), вставку и извлечение за \( O(\log n) \); на ней построены приоритетная очередь и heap sort.
• В физических расчётах деревья ускоряют поиск соседей (k-d деревья), задачу N тел (октодеревья Барнса — Хата) и хранят иерархические данные в HDF5.

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

Графы

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

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

К графам сводится множество практических задач, на первый взгляд не имеющих к ним отношения.

Слайды к главе. Определения, способы хранения графа, обходы в глубину и в ширину, компоненты связности и перколяция изложены также в шестой части лекции «Хеши, деревья и графы» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Определения

Граф \( G = (V, E) \) складывается из множества вершин \( V \) (англ. vertices) и множества рёбер \( E \) (англ. edges), каждое из которых соединяет пару вершин.

Основные разновидности:

• Неориентированный граф имеет рёбра, не снабжённые направлением: если из \( u \) можно попасть в \( v \), то и обратно тоже (дороги с двусторонним движением).
• Ориентированный граф (орграф, англ. directed graph) снабжает рёбра направлением, и ребро \( (u, v) \), проведённое в одну сторону, не означает существования ребра \( (v, u) \) (односторонние улицы, ссылки между веб-страницами, зависимости, связывающие задачи).
• Взвешенный граф приписывает каждому ребру число: длину дороги, сопротивление проводника, пропускную способность канала, энергию связи.

Терминология:

• смежными называются вершины, соединённые ребром;
• степень вершины равна числу рёбер, инцидентных ей (в орграфе различают входящую и исходящую степени);
• путь есть последовательность вершин, в которой соседние соединены рёбрами;
• цикл представляет собой путь, начинающийся и заканчивающийся в одной вершине;
• связный граф позволяет добраться из любой вершины до любой другой;
• компонента связности составляет максимальную связную часть графа;
• петля соединяет вершину с самой собой, а кратными рёбрами называются несколько рёбер, проведённых между одной парой вершин.

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

Способы хранения графа

От способа хранения зависят объём памяти и сложность операций; основных вариантов два.

Матрица смежности

Квадратная таблица \( n \times n \), где на пересечении \( i \)-й строки и \( j \)-го столбца стоит единица (или вес ребра), если ребро, ведущее из \( i \) в \( j \), существует, и ноль в противном случае. У неориентированного графа матрица симметрична.

n = 5
matrix = [[0] * n for _ in range(n)]  # граф без рёбер

def add_edge_matrix(matrix, u, v, directed=False):
    """Добавляет ребро в матрицу смежности (вершины нумеруются с нуля)."""
    matrix[u][v] = 1
    if not directed:
        matrix[v][u] = 1

Проверка наличия ребра между \( u \) и \( v \) выполняется за \( O(1) \). Однако памяти требуется \( O(n^2) \) независимо от числа рёбер, а перебор всех соседей вершины требует \( O(n) \), поскольку приходится просмотреть всю строку, даже если сосед всего один.

Список смежности

Для каждой вершины хранится список соседей, связанных с ней ребром.

from collections import defaultdict

graph = defaultdict(list)

def add_edge_list(graph, u, v, directed=False):
    """Добавляет ребро в список смежности."""
    graph[u].append(v)
    if not directed:
        graph[v].append(u)

Памяти требуется \( O(n + m) \), где \( m \) — число рёбер, а перебор соседей занимает время, пропорциональное их количеству. Платой является проверка конкретного ребра за \( O(\deg u) \) вместо \( O(1) \).

Выбор между ними. Для плотного графа, где число рёбер сравнимо с \( n^2 \), применяется матрица, для разреженного, где рёбер порядка \( n \), — список. Реальные графы почти всегда разреженные: у человека в социальной сети сотни друзей, а не миллионы, у атома в молекуле единицы связей. По умолчанию выбирается список смежности.

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

Обходы графа

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

Поиск в глубину (DFS)

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

def dfs_recursive(graph, vertex, visited=None):
    """Рекурсивный обход в глубину. Возвращает вершины в порядке обхода."""
    if visited is None:
        visited = set()
    visited.add(vertex)
    order = [vertex]
    for neighbour in sorted(graph[vertex]):
        if neighbour not in visited:
            order.extend(dfs_recursive(graph, neighbour, visited))
    return order

Рекурсивная запись удобна для чтения, но опасна на практике. Глубина рекурсии в Python по умолчанию ограничена примерно 1000, и если путь обхода длиннее тысячи вершин, например на цепочке из ста тысяч вершин, программа завершится с RecursionError. Поэтому DFS реализуют итеративно, заменяя стек вызовов явным стеком:

def dfs_iterative(graph, start):
    """Итеративный обход в глубину через явный стек."""
    visited = set()
    order = []
    stack = [start]
    while stack:
        vertex = stack.pop()
        if vertex in visited:
            continue
        visited.add(vertex)
        order.append(vertex)
        # соседей кладём в обратном порядке, чтобы снимать по возрастанию
        for neighbour in sorted(graph[vertex], reverse=True):
            if neighbour not in visited:
                stack.append(neighbour)
    return order

Проверка if vertex in visited стоит после снятия со стека, а не только перед добавлением. Одна и та же вершина попадает в стек по нескольку раз от разных соседей, поэтому отсеивать её необходимо в момент обработки.

Поиск в ширину (BFS)

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

from collections import deque

def bfs(graph, start):
    """Обход в ширину. Возвращает вершины в порядке обхода."""
    visited = {start}
    order = []
    queue = deque([start])
    while queue:
        vertex = queue.popleft()          # берём из начала очереди
        order.append(vertex)
        for neighbour in sorted(graph[vertex]):
            if neighbour not in visited:
                visited.add(neighbour)    # помечаем сразу при добавлении
                queue.append(neighbour)
    return order

В BFS вершина помечается посещённой в момент добавления в очередь, иначе она успеет попасть туда несколько раз.

Оба обхода работают за \( O(n + m) \): каждая вершина обрабатывается один раз, а каждое ребро просматривается один раз в ориентированном графе и дважды в неориентированном. Вызов sorted внутри приведённого обхода добавляет \( O(m \log n) \) и присутствует там ради воспроизводимого вывода. В рабочем коде списки смежности сортируют один раз заранее, как в задачах в конце главы. Выбор между двумя обходами определяется задачей:

• BFS посещает вершины в порядке возрастания расстояния, отсчитанного от старта, поэтому он находит кратчайшие пути в невзвешенном графе;
• DFS естественно записывается через рекурсию и применяется для поиска циклов, топологической сортировки, компонент связности и анализа структуры графа.

Слайды к главе. Кратчайшие пути, топологическая сортировка и минимальное остовное дерево изложены также в седьмой части лекции «Хеши, деревья и графы»; слайды лекции доступны на сайте книги и в PDF.

Кратчайшие пути

В невзвешенном графе кратчайший путь находит BFS, попутно запоминая расстояние и предка каждой вершины.

def bfs_shortest_paths(graph, start):
    """Расстояния (в рёбрах) и предки на кратчайших путях от start."""
    dist = {start: 0}
    parent = {start: None}
    queue = deque([start])
    while queue:
        vertex = queue.popleft()
        for neighbour in graph[vertex]:
            if neighbour not in dist:
                dist[neighbour] = dist[vertex] + 1
                parent[neighbour] = vertex
                queue.append(neighbour)
    return dist, parent

Путь восстанавливается проходом от конечной вершины по ссылкам parent до старта и разворотом полученного списка.

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

import heapq

def dijkstra(graph, start):
    """Кратчайшие расстояния во взвешенном графе с неотрицательными весами.

    graph — список смежности вида {вершина: [(сосед, вес), ...]}.
    """
    dist = {start: 0}
    heap = [(0, start)]           # приоритетная очередь (расстояние, вершина)
    while heap:
        d, vertex = heapq.heappop(heap)
        if d > dist.get(vertex, float("inf")):
            continue              # устаревшая запись, вершина уже обработана
        for neighbour, weight in graph[vertex]:
            new_dist = d + weight
            if new_dist < dist.get(neighbour, float("inf")):
                dist[neighbour] = new_dist
                heapq.heappush(heap, (new_dist, neighbour))
    return dist

Куча, рассмотренная в главе про деревья, обеспечивает сложность \( O(m \log n) \). Приведённая реализация не уменьшает ключ записи, уже лежащей в куче, а кладёт в кучу новую запись; устаревшая запись, расстояние в которой больше текущей оценки, при извлечении пропускается. Веса обязаны быть неотрицательными: иначе вершина, уже снятая с кучи, может получить лучшую оценку, и оценка сложности перестаёт выполняться; для графов с отрицательными рёбрами применяют алгоритм Беллмана — Форда, который требует \( O(nm) \) и обнаруживает циклы отрицательного веса.

Топологическая сортировка

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

Простейший способ — DFS: вершина добавляется в результат после всех потомков, а список в конце разворачивается. Чтобы обнаружить цикл, вершины различают тремя цветами: не посещённая, находящаяся в обработке и обработанная. Вершина, встреченная повторно, пока она ещё в обработке, лежит на текущем пути обхода, и ребро в неё замыкает цикл.

def topological_sort(graph, vertices):
    """Топологическая сортировка; при цикле возбуждает ValueError."""
    WHITE, GRAY, BLACK = 0, 1, 2  # не посещена, в обработке, обработана
    color = {vertex: WHITE for vertex in vertices}
    order = []

    def visit(vertex):
        color[vertex] = GRAY
        for neighbour in graph[vertex]:
            if color[neighbour] == GRAY:      # вершина на текущем пути
                raise ValueError(f"цикл через вершину {neighbour}")
            if color[neighbour] == WHITE:
                visit(neighbour)
        color[vertex] = BLACK
        order.append(vertex)      # добавляем на выходе из вершины

    for vertex in vertices:
        if color[vertex] == WHITE:
            visit(vertex)
    return order[::-1]            # разворачиваем

На графе \( a \to b \to c \to a \) функция возбуждает ValueError: цикл через вершину a; без проверки цвета она вернула бы порядок ['a', 'b', 'c'], нарушающий ребро \( c \to a \), без какой-либо ошибки. Рекурсивная функция visit к тому же исчерпает предел рекурсии на цепочке длиннее тысячи вершин. Без рекурсии обходится алгоритм Кана: он подсчитывает для каждой вершины число входящих рёбер, ставит в очередь вершины без входящих рёбер и, снимая вершину, уменьшает счётчики её соседей; если в итоге упорядочены не все вершины, в графе есть цикл. Оба способа требуют \( O(n + m) \).

В стандартной библиотеке начиная с Python 3.9 есть класс graphlib.TopologicalSorter, который при цикле возбуждает исключение graphlib.CycleError. Он принимает словарь, сопоставляющий вершине её предшественников, то есть рёбра в нём записаны в обратную сторону по сравнению со списками смежности; переданные без разворота списки смежности дали бы обратный порядок без какой-либо ошибки.

from graphlib import TopologicalSorter, CycleError

deps = {"b": ["a"], "c": ["b"]}    # вершина -> её предшественники
print(list(TopologicalSorter(deps).static_order()))   # ['a', 'b', 'c']

deps["a"] = ["c"]                  # a зависит от c: цикл
try:
    list(TopologicalSorter(deps).static_order())
except CycleError as err:
    print("цикл:", err.args[1])    # цикл: ['b', 'c', 'a', 'b']

Минимальное остовное дерево

Остовным деревом (англ. spanning tree) связного графа называется подмножество рёбер, связывающее все вершины и не содержащее циклов, то есть дерево, натянутое на все \( n \) вершин и собранное из \( n-1 \) ребра. Минимальным остовным деревом (MST) называется то, у которого суммарный вес рёбер наименьший. Классическая постановка требует соединить все дома оптоволокном, затратив минимум кабеля.

Два классических алгоритма, оба жадные:

• Алгоритм Прима наращивает дерево из одной вершины: на каждом шаге добавляется самое лёгкое ребро, ведущее из уже построенной части наружу. Удобно реализуется через кучу, сложность \( O(m \log n) \). По существу это алгоритм Дейкстры, только вместо расстояния от старта минимизируется вес одного ребра.
• Алгоритм Краскала исходит от рёбер: сортирует их все по весу и добавляет по очереди те, которые не образуют цикл. Проверка на цикл выполняется структурой «система непересекающихся множеств» (DSU): с сокращением путей и объединением по рангу её операции выполняются амортизированно почти за \( O(1) \), и сложность определяется сортировкой рёбер, \( O(m \log m) \).

Если в алгоритме Прима заменить «минимальное ребро» на «максимальное», получится максимальное остовное дерево; эта задача рассматривается в конце главы.

Графы в физических задачах

• Электрические цепи. Схема представляет собой граф из узлов и ветвей. Законы Кирхгофа записываются через матрицу инцидентности, а число независимых контурных уравнений равно \( m - n + 1 \), то есть количеству рёбер, не вошедших в остовное дерево: каждое такое ребро вместе с путём по остову замыкает свой независимый контур, хотя эти контуры не обязаны совпадать с ячейками схемы.
• Модель Изинга и перколяция. Спины на решётке служат вершинами, а взаимодействия соседей рёбрами. Алгоритмы кластерного обновления (Свендсена — Ванга, Вольфа) сводятся к поиску компонент связности, а перколяция — вопрос о существовании компоненты, соединяющей края решётки; на квадратной решётке, узлы которой заняты независимо с вероятностью \( p \), такая компонента в пределе бесконечной решётки появляется при \( p > p_c \approx 0{,}5927 \).
• Молекулы и структуры. Атомы и химические связи образуют граф, а поиск колец в молекуле сводится к поиску циклов. На этом же представлении работают графовые нейронные сети, предсказывающие свойства веществ.
• Марковские цепи и графы состояний. Состояния системы становятся вершинами, а переходы, снабжённые вероятностями, взвешенными рёбрами орграфа.
• Трассировка и планирование. Разводка кабелей на установке, маршрут манипулятора, план эксперимента сводятся к задачам о кратчайшем пути или об остовном дереве.

Для практических расчётов реализовывать алгоритмы вручную не обязательно: готовые собраны в библиотеке NetworkX.

import networkx as nx

# граф-решётка 4 x 4 — например, узлы двумерной модели Изинга
lattice = nx.grid_2d_graph(4, 4)

print(nx.number_connected_components(lattice))       # компоненты связности
print(nx.shortest_path(lattice, (0, 0), (3, 3)))     # кратчайший путь
mst = nx.minimum_spanning_tree(lattice)              # остовное дерево

Разбираться в устройстве алгоритмов всё равно необходимо: библиотека не подскажет, что поставленная задача сводится к поиску компонент связности.

Разбор задач

Задачи рекомендуется сначала решить самостоятельно; они собраны в тренажёре.

Во всех задачах вершины нумеруются с единицы, а граф подаётся на вход списком рёбер: в первой строке числа \( n \) и \( m \), задающие количество вершин и рёбер, далее \( m \) строк с парами вершин.

Задача 1. Построить список смежности

Условие. Дан ориентированный граф, заданный списком рёбер. Требуется построить его список смежности: для каждой вершины \( i \) вывести число исходящих рёбер, а затем номера вершин, в которые они ведут, в порядке возрастания.

Идея решения. Прямая реализация определения. Заведём список списков и пройдём по рёбрам, добавляя конец каждого ребра в список его начала. Сортировка выполняется один раз в конце.

n, m = map(int, input().split())
graph = [[] for _ in range(n + 1)]        # вершины нумеруются с единицы

for _ in range(m):
    u, v = map(int, input().split())
    graph[u].append(v)                    # граф ориентированный: только u -> v

for vertex in range(1, n + 1):
    neighbours = sorted(graph[vertex])
    print(len(neighbours), *neighbours)

Сложность. По времени \( O(n + m \log n) \), поскольку чтение рёбер стоит \( O(m) \), а сортировка списков смежности даёт в сумме \( \sum_i d_i \log d_i \le m \log n \). По памяти \( O(n + m) \).

Задача 2. Перевести список рёбер в матрицу смежности

Условие. Дан ориентированный граф, заданный списком рёбер. Требуется вывести его матрицу смежности \( n \times n \): на пересечении \( i \)-й строки и \( j \)-го столбца стоит единица, если существует ребро, ведущее из \( i \) в \( j \).

Идея решения. Заведём нулевую матрицу и расставим единицы. Единственная тонкость заключается в том, что матрицу нельзя создавать через [[0] * n] * n. В этом случае получится \( n \) ссылок на один и тот же список, и запись в одну строку изменит все разом; устройство этой ловушки рассмотрено в главе про объекты и память.

n, m = map(int, input().split())
matrix = [[0] * n for _ in range(n)]      # именно так, а не [[0] * n] * n

for _ in range(m):
    u, v = map(int, input().split())
    matrix[u - 1][v - 1] = 1              # переходим к нумерации с нуля

for row in matrix:
    print(*row)

Сложность. По времени \( O(n^2 + m) \), поскольку один вывод матрицы уже стоит \( O(n^2) \); по памяти \( O(n^2) \).

Задача 3. Обход в глубину

Условие. Задан неориентированный граф. Требуется обойти с помощью DFS все вершины, достижимые из заданной вершины \( s \), и вывести их в порядке обхода. Соседи каждой вершины рассматриваются в порядке возрастания номеров.

Идея решения. Итеративный DFS со стеком, поскольку граф может содержать до \( 10^5 \) вершин, и на длинном пути обхода, например на цепочке, рекурсия, ограниченная тысячей кадров, с этим не справится. Чтобы соседи обрабатывались по возрастанию, поместим их в стек в обратном порядке: снимается всегда последний положенный.

n, m = map(int, input().split())
graph = [[] for _ in range(n + 1)]

for _ in range(m):
    u, v = map(int, input().split())
    graph[u].append(v)
    graph[v].append(u)                    # граф неориентированный

start = int(input())
for neighbours in graph:
    neighbours.sort(reverse=True)         # сортируем один раз заранее

visited = [False] * (n + 1)
stack, order = [start], []

while stack:
    vertex = stack.pop()
    if visited[vertex]:                   # вершина могла попасть в стек несколько раз
        continue
    visited[vertex] = True
    order.append(vertex)
    for neighbour in graph[vertex]:
        if not visited[neighbour]:
            stack.append(neighbour)

print(*order)

Сложность. По времени \( O(n + m) \) плюс сортировка списков смежности, выполненная заранее; по памяти \( O(n + m) \).

Задача 4. Обход в ширину

Условие. Постановка та же, но обход выполняется в ширину.

Идея решения. Заменим стек на deque и будем снимать элементы с начала; соседей отсортируем уже по возрастанию, а вершину, добавляемую в очередь, сразу пометим посещённой.

from collections import deque

n, m = map(int, input().split())
graph = [[] for _ in range(n + 1)]

for _ in range(m):
    u, v = map(int, input().split())
    graph[u].append(v)
    graph[v].append(u)

start = int(input())
for neighbours in graph:
    neighbours.sort()

visited = [False] * (n + 1)
visited[start] = True
queue, order = deque([start]), []

while queue:
    vertex = queue.popleft()              # берём из начала очереди
    order.append(vertex)
    for neighbour in graph[vertex]:
        if not visited[neighbour]:
            visited[neighbour] = True     # помечаем сразу при добавлении
            queue.append(neighbour)

print(*order)

Сложность. Та же, что и у DFS: \( O(n + m) \) по времени и памяти. Коды двух обходов различаются контейнером, порядком перебора соседей и моментом пометки вершины.

Задача 5. Компоненты связности

Условие. Дан неориентированный граф. Требуется найти его компоненты связности: вывести их количество, а затем вершины каждой компоненты по возрастанию. Компоненты упорядочены по номеру первой вершины.

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

n, m = map(int, input().split())
graph = [[] for _ in range(n + 1)]

for _ in range(m):
    u, v = map(int, input().split())
    graph[u].append(v)
    graph[v].append(u)

visited = [False] * (n + 1)
components = []

for vertex in range(1, n + 1):
    if visited[vertex]:
        continue
    component, stack = [], [vertex]       # новая компонента
    while stack:
        current = stack.pop()
        if visited[current]:
            continue
        visited[current] = True
        component.append(current)
        stack.extend(graph[current])
    components.append(sorted(component))

print(len(components))
for component in components:
    print(*component)

Сложность. По времени \( O(n + m) \) плюс сортировка найденных компонент, по памяти \( O(n + m) \). Заметим, что внешний цикл по вершинам, вопреки первому впечатлению, не делает алгоритм квадратичным: каждая вершина обрабатывается по одному разу, а цикл лишь ищет стартовые точки.

Задача 6. Самая дорогая сеть

Условие. Дан взвешенный неориентированный граф. Требуется найти вес максимального остовного дерева — набора рёбер, связывающего все вершины и имеющего наибольший суммарный вес. Если граф несвязен, дерева, натянутого на все вершины, не существует.

Идея решения. Алгоритм Прима, в котором на каждом шаге выбирается не минимальное, а максимальное ребро. Модуль heapq до версии 3.13 включительно реализует лишь min-heap, поэтому в кучу помещается вес со знаком минус: «минимальный» элемент кучи окажется максимальным по модулю.

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

import heapq

def add_vertex(vertex, graph, added, heap):
    """Добавляет вершину в остов и кладёт её рёбра в кучу."""
    added[vertex] = True
    for neighbour, weight in graph[vertex]:
        if not added[neighbour]:
            heapq.heappush(heap, (-weight, neighbour))   # минус: нужен max-heap

n, m = map(int, input().split())
graph = [[] for _ in range(n + 1)]

for _ in range(m):
    u, v, weight = map(int, input().split())
    graph[u].append((v, weight))
    graph[v].append((u, weight))

added = [False] * (n + 1)
added[0] = True                           # нулевой вершины не существует
heap, total = [], 0

add_vertex(1, graph, added, heap)         # растим остов из первой вершины
in_tree = 1                               # сколько вершин уже в остове

while in_tree < n and heap:
    weight, vertex = heapq.heappop(heap)
    if not added[vertex]:                 # ребро внутрь остова пропускаем
        total += -weight
        add_vertex(vertex, graph, added, heap)
        in_tree += 1

print(total if in_tree == n else "Oops! I did it again")

Сложность. По времени \( O(m \log n) \), поскольку каждое ребро попадает в кучу не более одного раза, а операции с кучей стоят \( O(\log n) \). По памяти \( O(n + m) \).

Резюме

• Граф является самой общей структурой, описывающей связи; дерево и список — его частные случаи.
• Разреженные графы хранятся списком смежности, занимающим \( O(n+m) \) памяти, а плотные матрицей смежности: \( O(n^2) \), зато проверка ребра за \( O(1) \).
• DFS и BFS отличаются контейнером для вершин — стеком или очередью — и моментом пометки вершины, и оба работают за \( O(n + m) \).
• BFS находит кратчайшие пути в невзвешенном графе, а алгоритм Дейкстры во взвешенном с неотрицательными весами за \( O(m \log n) \).
• Посещённые вершины необходимо помечать: в отличие от дерева, у графа есть циклы, и без пометок обход не завершится.
• Компоненты связности, топологическая сортировка и остовные деревья — три классических применения обходов, к которым сводится множество практических задач.

Жизненный цикл программного обеспечения

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

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

Слайды к главе. Материал главы изложен также в лекции «Жизненный цикл ПО» (анализ и проектирование, разработка, тестирование, релиз, CI/CD, сопровождение) с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Основные стадии жизненного цикла

Жизненный цикл ПО принято делить на стадии; в настоящей главе их семь:

1. Анализ. Выясняется, что именно требуется построить.
2. Проектирование. Определяется, как это будет устроено.
3. Разработка. Пишется код.
4. Тестирование. Проверяется, что получилось именно задуманное.
5. Релиз. Продукт доводится до пользователя.
6. Сопровождение. Работающая система наблюдается и поддерживается.
7. Завершение жизненного цикла. Продукт снимается с поддержки.

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

Анализ и планирование

На этапе анализа собираются требования к будущему продукту и сводятся в документ — спецификацию требований к программному обеспечению (Software Requirements Specification, SRS).

Спецификация требований

Структуру спецификации задавал стандарт IEEE 830-1998. В 2011 году его заменил стандарт ISO/IEC/IEEE 29148 (действующая редакция — 2018 года), однако основное содержание документа сохранилось. Спецификация состоит из трёх частей:

1. Введение: назначение документа и продукта, его границы, термины и ссылки.
2. Общее описание: место продукта среди других систем, основные функции, пользователи, окружение, ограничения и допущения.
3. Конкретные требования: внешние интерфейсы и форматы данных, функции, производительность, проектные ограничения и атрибуты качества — надёжность, точность, сопровождаемость.

Сроки и бюджет в спецификацию не включают: это требования к проекту, а не к продукту, и они фиксируются в плане работ. В отечественной практике документ с требованиями называют техническим заданием. Его содержание для программ устанавливает ГОСТ 19.201-78, для автоматизированных систем — ГОСТ 34.602-2020; техническое задание на систему, кроме требований к ней, определяет состав и этапы работ, порядок контроля и приёмки.

Ключевые задачи этапа анализа

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

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

Проектирование

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

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

Design-review

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

• что планируется сделать;
• мотивация, то есть цели, заказчики и пользователи;
• сравнение с уже существующими аналогами;
• план работ (roadmap).

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

Security-review

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

Проверка паролей, написанная самостоятельно, остаётся типичной уязвимостью лабораторных сервисов. Сделанная за один вечер, она затем годами пропускает внутрь кого угодно, поэтому проверку доступа поручают готовым средствам, например SSH и единому входу организации. Разбор не заканчивается запуском: сервис со временем начинает обрабатывать новые данные, и хранилище, одобренное для открытых данных, оказывается открытым и для закрытых.

MVP (Minimum Viable Product)

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

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

Разработка

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

Системы контроля версий

Система контроля версий (VCS) хранит историю изменений с указанием того, кто, что и когда правил, и позволяет вернуться к любому прошлому состоянию. Решать эту задачу начали в 1960-х программой IEBUPDTE, затем появились SCCS в 1970-х, RCS и CVS в 1980-х, Subversion и Git в 2000-х.

Поколения различаются тем, где хранится история. Централизованные системы (CVS, Subversion) хранят её на сервере, и без связи с ним нельзя ни просмотреть историю, ни сделать коммит. Распределённые системы (Git, Mercurial) дают каждому участнику полную копию репозитория со всей историей, поэтому работать можно без сети, а синхронизироваться впоследствии.

Стандартом де-факто является Git, написанный Линусом Торвальдсом в 2005 году для разработки ядра Linux, когда команда лишилась бесплатного доступа к использовавшейся до того проприетарной системе BitKeeper. Главной его особенностью является дешёвое ветвление. Ветка — указатель на коммит, поэтому её создание ничего не копирует, и ветвиться и сливать можно постоянно. Команда git switch -c feature создаёт ветку и переключается на неё (прежняя форма — git checkout -b feature), а git merge feature сливает её изменения в текущую ветку. Если обе ветки изменили одни и те же строки, возникает конфликт слияния: Git помечает спорные строки, а решение принимает человек. Устройству Git и повседневным командам посвящена отдельная глава.

Вокруг ветвления сложились схемы работы:

• Git Flow держит две постоянные ветки, main и develop, и заводит на время ветки функций, релизов и срочных исправлений, которые удаляются после слияния. Схема подходит для продуктов с редкими версионированными релизами.
• GitHub Flow проще: основная ветка всегда находится в рабочем состоянии, каждая задача делается в короткой ветке и вливается через pull request после ревью.
• GitLab Flow дополняет GitHub Flow ветками окружений или долгоживущими ветками релизов, через которые изменения проходят по стендам.
• Магистральная разработка (trunk-based development) сокращает жизнь веток до дня и опирается на непрерывную интеграцию и feature-флаги.

Выбор определяется тем, как часто выходят релизы и сколько версий одновременно поддерживается. Научной группе почти всегда достаточно самой простой схемы, GitHub Flow.

Ревью кода

Pull request (или merge request) — предложение влить в общую ветку сделанные разработчиком изменения. Он решает три задачи: делает правку видимой для всей команды, предоставляет место для обсуждения до того, как код попал в основную ветку, и служит точкой, к которой привязываются автоматические проверки.

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

Споры о форме снимают единые требования к коду: стиль определяется соглашением, а не вкусом автора, и проверяют его линтер и форматтер. Хук pre-commit в каталоге .git/hooks запускает проверки перед каждым коммитом и не даёт зафиксировать код, который их не проходит. Хук обходится ключом --no-verify и не копируется при клонировании, поэтому проверки на сервере он не заменяет; общий для всех участников набор хуков описывают файлом .pre-commit-config.yaml фреймворка pre-commit.

Монорепозиторий

Монорепозиторий хранит код нескольких проектов вместе, под общей системой сборки и тестирования. Это упрощает управление зависимостями (все компоненты всегда согласованной версии), облегчает работу через границы команд и позволяет вносить сквозные изменения одним коммитом, а не пятью, разложенными по репозиториям. Платой являются разросшийся репозиторий и более сложные инструменты сборки, проверяющие только затронутые части. Монорепозитории используют крупные компании, в том числе Яндекс и Google; большинство открытых проектов живёт в отдельных репозиториях.

В монорепозитории удобно хранить и копии сторонних зависимостей: сборка не зависит от того, что удалят или подменят в чужом репозитории. В 2016 году автор пакета left-pad из одиннадцати строк удалил его из npm, и на несколько часов перестали собираться тысячи проектов; в 2024 году в библиотеку xz один из сопровождающих внёс бэкдор, попадавший в сборку через архивы релизов. Копия защищает только при закреплённых версиях и проверке каждого обновления.

Лаборатории разумно держать в одном репозитории всё, что выпускается и версионируется вместе, и разносить части, развивающиеся независимо.

Тестирование

Проверка вручную после каждой правки быстро становится невыполнимой. Автоматические тесты позволяют один раз описать требуемое поведение и в дальнейшем проверять его одной командой.

Проверки удобно выстроить пирамидой по цене и частоте запуска. Классическая пирамида тестов (М. Кон, 2009) состоит из модульных, интеграционных и сквозных тестов через интерфейс пользователя; в основание часто кладут статический анализ, не запускающий программу. Внизу проверки дешёвые и быстрые: их много, и они запускаются на каждое изменение. Вверху — дорогие и медленные: их мало, и они запускаются перед релизом. Нагрузочные тесты стоят особняком: они проверяют не правильность, а производительность.

Статический анализ

Самая дешёвая проверка не запускает программу. Анализатор читает исходный код и ищет в нём ошибки, отклонения от стиля и уязвимости: неиспользуемые переменные и импорты, опечатки в именах, сравнение с None через ==, голые except; по аннотациям типов mypy находит передачу значения не того типа. По сути это автоматизированная часть ревью, но не его замена. В отчёты о качестве попадают и метрики: цикломатическая сложность и доля дублированных строк. Туда же попадает покрытие тестами, однако получают его иначе, выполняя тесты под coverage.py (coverage run -m pytest, а с плагином pytest-cov — pytest --cov): узнать, какие строки выполнялись, не выполнив их, нельзя.

Анализатор, встроенный в редактор и в CI, в дальнейшем работает самостоятельно. Набор его правил задают в pyproject.toml явно: правила по умолчанию меняются от версии к версии, и в ruff 0.16 из них исключены, например, проверки сравнения с None и импорта со звёздочкой.

«Самое важное, что я сделал как программист за последние годы, — начал агрессивно применять статический анализ кода» — Джон Кармак, 2011

Модульные тесты

Модульный тест (unit test) проверяет одну функцию или класс, отделённые от всего остального. Их пишут много, они выполняются за секунды и запускаются на каждое изменение, поэтому ошибка, внесённая правкой, обнаруживается сразу.

Для научного кода это самая ценная разновидность тестов. Формулу проверяют на случаях с известным ответом, в предельных случаях и на инвариантах. Рассмотрим модуль physics.py с релятивистскими формулами:

"""Релятивистские формулы для пучка."""

import math

C = 299_792_458.0  # скорость света, м/с


def gamma(v):
    """Лоренц-фактор частицы со скоростью v, м/с."""
    if not 0 <= v < C:
        raise ValueError("ожидается 0 <= v < c")
    return 1 / math.sqrt(1 - (v / C) ** 2)


def kinetic_energy(m, v):
    """Кинетическая энергия, Дж: масса m в кг, скорость v в м/с."""
    return (gamma(v) - 1) * m * C**2

Тесты к нему лежат в файле test_physics.py:

import pytest

from physics import C, gamma, kinetic_energy


@pytest.mark.parametrize(
    "beta, expected", [(0.0, 1.0), (0.6, 1.25), (0.8, 5 / 3)]
)
def test_gamma_known_values(beta, expected):
    assert gamma(beta * C) == pytest.approx(expected)


def test_gamma_rejects_light_speed():
    with pytest.raises(ValueError):
        gamma(C)


def test_kinetic_energy_classical_limit():
    m, v = 1.0, 1e3  # скорость много меньше c
    assert kinetic_energy(m, v) == pytest.approx(m * v**2 / 2, rel=1e-6)

Декоратор parametrize прогоняет один тест на нескольких наборах данных, pytest.raises проверяет, что функция отвергает недопустимый вход, а pytest.approx сравнивает вещественные числа с допуском. Подробнее pytest рассмотрен в главе «От скрипта к приложению».

Тест предельного случая не проходит: при скорости 1000 м/с функция возвращает 500 006,9 Дж вместо 500 000. Ошибка не в физике, а в арифметике. Величина \(\gamma - 1 \approx 5{,}6 \cdot 10^{-12}\) получается вычитанием близких чисел, и из шестнадцати значащих цифр двойной точности в ней остаётся около пяти. Математически равная запись \((\gamma - 1) mc^2 = mv^2 \gamma^2 / (\gamma + 1)\) близкие числа не вычитает:

def kinetic_energy(m, v):
    """Кинетическая энергия, Дж: масса m в кг, скорость v в м/с."""
    return m * v**2 * gamma(v) ** 2 / (gamma(v) + 1)

С ней проходят все пять тестов. Тест предельного случая обнаружил ошибку, которую не видно на релятивистских скоростях; проверенная однажды, формула остаётся проверенной и после того, как через полгода её начнут оптимизировать.

Разработка через тестирование (TDD)

В примере выше тесты написаны к готовому коду. Разработка через тестирование (test-driven development, TDD), описанная К. Беком (2002), меняет порядок работы. Сначала пишется тест, фиксирующий требование, и он не проходит, поскольку кода ещё нет; затем пишется простейший код, с которым тест проходит; затем при проходящих тестах код приводится в порядок (рефакторинг), в частности из него убирается дублирование, допущенное ради быстрого прохождения теста (принцип DRY рассмотрен в главе «Требования к коду»). Цикл «красный — зелёный — рефакторинг», названный по цвету отчёта о тестах, повторяется для каждого требования. Тест, написанный до кода, проверяет требование, а не реализацию, тогда как тест, составленный по готовому коду, нередко принимает за норму то, что код делает, вместе с его ошибками.

Рассмотрим функцию, проверяющую адреса приборов в файле конфигурации. Требование сформулируем так: адрес IPv4 записывается четырьмя десятичными числами от 0 до 255 через точку, без ведущих нулей (адресация рассмотрена в главе «Компьютерные сети»). Тесты составлены по пунктам требования и лежат в файле test_ipv4.py:

import pytest

from ipv4 import is_ipv4

VALID = ("8.8.8.8", "192.0.2.10", "255.255.255.255")
INVALID = ("", "a.b.c.d", "256.1.1.1", "8.8.8.8.8")
# три числа, ведущий нуль, шестнадцатеричная запись, одно число
STRICT = ("8.8.8", "010.0.0.1", "0x08080808", "134744072")


@pytest.mark.parametrize("text", VALID)
def test_valid(text):
    assert is_ipv4(text)


@pytest.mark.parametrize("text", INVALID + STRICT)
def test_invalid(text):
    assert not is_ipv4(text)

Первая реализация в модуле ipv4.py поручает разбор адреса стандартной функции socket.inet_aton:

import socket


def is_ipv4(text):
    """Проверяет, является ли строка text адресом IPv4."""
    try:
        socket.inet_aton(text)
    except OSError:
        return False
    return True

python3 -m pytest -q --tb=no

.......FFFF                                                              [100%]
=========================== short test summary info ============================
FAILED test_ipv4.py::test_invalid[8.8.8] - AssertionError: assert not True
FAILED test_ipv4.py::test_invalid[010.0.0.1] - AssertionError: assert not True
FAILED test_ipv4.py::test_invalid[0x08080808] - AssertionError: assert not True
FAILED test_ipv4.py::test_invalid[134744072] - AssertionError: assert not True
4 failed, 7 passed in 0.01s

Ключи -q и --tb=no сокращают отчёт до строки хода выполнения, перечня непрошедших тестов и итога. Очевидные случаи реализация проходит, строгие — нет. Функция inet_aton разбирает адрес по правилам, унаследованным от BSD Unix: в записи из трёх чисел последнее занимает два младших байта, и 8.8.8 означает 8.8.0.8; число с ведущим нулём читается как восьмеричное, и 010.0.0.1 превращается в 8.0.0.1; строки 0x08080808 и 134744072 представляют собой адрес 8.8.8.8, записанный целиком одним числом, шестнадцатеричным и десятичным. Поэтому проверка пропустила бы и опечатку 192.0.2 вместо 192.0.2.10: inet_aton читает её как адрес 192.0.0.2. Документация Python к тому же оговаривает, что набор допустимых строк зависит от реализации библиотеки C. Разбор, соответствующий требованию, выполняет класс ipaddress.IPv4Address; ведущие нули он отвергает начиная с Python 3.9.5:

import ipaddress


def is_ipv4(text):
    """Проверяет, является ли строка text адресом IPv4."""
    try:
        ipaddress.IPv4Address(text)
    except ipaddress.AddressValueError:
        return False
    return True

С новой реализацией та же команда показывает, что проходят все одиннадцать тестов:

...........                                                              [100%]
11 passed in 0.00s

Тест, написанный по требованию, обнаружил ошибку при первом запуске, а тест, составленный по результатам готовой функции, скорее всего закрепил бы 8.8.8 как допустимый адрес. Считать ли такую запись адресом — вопрос спецификации, а не тестирования: inet_aton её принимает, а сформулированное выше требование отвергает. Таким образом, тест лишь фиксирует выбранную спецификацию, и выбирают её до написания тестов.

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

Интеграционные и функциональные тесты

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

Функциональные тесты проверяют, что программа делает записанное в требованиях, с точки зрения работающего с ней человека: через пользовательский или программный интерфейс, вручную или автоматически (для веб-интерфейсов — средствами вроде Selenium). У лабораторного инструмента сквозной функциональный тест обычно один. Он берёт снятый с установки эталонный файл, выполняет всю обработку от начала до конца и сравнивает итоговые числа с заведомо правильными.

Нагрузочное тестирование

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

Общим словом performance testing называют все испытания производительности. Перед замером подают небольшой прогревающий поток запросов (warm-up), наполняющий кеши, иначе первые минуты измерений искажены. Это актуально и для физика: программа, быстро считающая на прогретых кешах, на первом запуске ведёт себя иначе. Для нагрузки используют JMeter, Siege, Яндекс.Танк, на Python — locust. Нагрузку подают на отдельное окружение, а не на рабочую систему, и обращения к внешним сервисам заменяют заглушками: иначе тест нарушит работу коллег или будет воспринят чужим сервисом как атака.

Релиз

Главной заботой при выкатке является возможность быстро откатиться в случае поломки.

Стратегии развёртывания

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

• Blue-green. Поддерживаются две одинаковые среды. Новая версия выкатывается на неактивную, проверяется, и трафик переключается одним действием. Откат — переключение обратно. Плата — удвоенные ресурсы, а схема общей базы данных должна подходить обеим версиям.
• Canary. Новая версия сначала показывается небольшой доле пользователей. Если число ошибок и потребление ресурсов не выросли, доля увеличивается. Проблема затрагивает немногих, а откат быстрый, но выкатка медленнее.
• Rolling update. Экземпляры приложения заменяются постепенно, по одному или группами, и сервис всё это время продолжает отвечать. Сколько экземпляров может быть недоступно одновременно и сколько добавляется сверх нормы, задают параметры выкатки (в Kubernetes — maxUnavailable и maxSurge).
• A/B-тестирование. Контролируемый эксперимент: пользователи случайным образом делятся на группы, каждая получает свою версию, и решение принимается по заранее выбранной метрике с проверкой статистической значимости. От канареечной выкатки его отличает цель — выбор лучшего варианта, а не безопасность выпуска.

Крупные сервисы сочетают канареечную выкатку, постепенную замену, feature-флаги и A/B-эксперименты.

Контейнеры

Выпуск удобно оформлять образом контейнера (см. главу «Docker»). Образ содержит приложение вместе со средой выполнения — интерпретатором, библиотеками, системными файлами — и после сборки не меняется. Тег образа служит версией: выкатка — запуск контейнера из нового тега, откат — запуск из предыдущего, и старый образ хранится готовым к повторному запуску. Тег при этом остаётся изменяемой ссылкой: его можно перенести на другой образ, а базовый python:3.12-slim обновляется с каждым выпуском 3.12.x. Неизменяемой ссылкой служит дайджест (python:3.12-slim@sha256:…). Образ работает на любой машине с той же архитектурой процессора; для разных машин собирают многоплатформенный образ (docker buildx build --platform linux/amd64,linux/arm64).

Feature-флаги

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

Версии и теги

Релиз получает номер версии, по которому его можно найти, установить и сослаться на него. Семантическое версионирование (SemVer) записывает версию тремя числами MAJOR.MINOR.PATCH: старшее увеличивается при несовместимом изменении интерфейса, среднее — при новых возможностях с сохранением совместимости, младшее — при исправлении ошибок. Версия фиксируется в Git аннотированным тегом: git tag -a v1.5.0 отмечает коммит, из которого собран релиз, а git describe показывает, сколько коммитов прошло с последнего тега. Список изменений между версиями ведут в файле CHANGELOG.

В статье указывают версию или хеш коммита кода, которым получен результат. Архив релиза с DOI, например через интеграцию GitHub с Zenodo, позволяет сослаться на код и воспроизвести расчёт спустя годы.

Момент выпуска

Мораторий на выкатки (change freeze) — период с запрещёнными выкатками: перед большой конференцией, во время набора данных на установке, в новогодние праздники, когда некому устранять неполадки. От него отличается feature freeze — этап цикла выпуска, после которого в версию принимают только исправления ошибок: в CPython он наступает с первой бета-версией. Релизные окна — заранее оговорённые промежутки, в которые выкатки разрешены, чтобы в этот момент на месте были люди, способные разобраться с последствиями.

CI/CD

Перечисленные проверки выполняет конвейер CI/CD. Без него разработчики занимаются сборкой и ручным тестированием вместо разработки, под давлением сроков тестирование пропускают, а при ручной выкатке легко ошибиться. За тремя похожими аббревиатурами скрываются три степени автоматизации.

Непрерывная интеграция (CI) — минимальный уровень. Код хранится в системе контроля версий, каждый push запускает сборку, модульные тесты и статический анализ, изменения проходят ревью. Поломка обнаруживается через минуты после появления, а не через недели.

Непрерывная поставка (CD, Continuous Delivery) добавляет хранение собранных дистрибутивов в централизованном хранилище и автоматическое развёртывание на тестовые среды. Система в любой момент готова к выкатке и ожидает решения человека.

Непрерывное развёртывание (CD, Continuous Deployment): прошедшие все проверки изменения попадают в продакшен без участия человека. Это требует уверенности в тестах.

Научной группе обычно достаточно первого уровня — конвейера, запускающего на каждый push тесты и линтер; он требует одного файла в репозитории. Конвейеры исполняют GitHub Actions, GitLab CI, Jenkins, TeamCity.

Устройство реального конвейера

Ниже в обновлённом виде приведён конвейер научной библиотеки REDPIC, кода для расчёта динамики пучка, которому отведена отдельная глава; в репозитории библиотеки он записан на более старых версиях действий. Конвейер написан для GitHub Actions и состоит из трёх файлов в каталоге .github/workflows.

Первый файл, check.yml, проверяет качество кода. Он запускается на push в основную ветку, затрагивающий файлы Python, и на каждый pull request в неё. Работа выполняется на чистой виртуальной машине и начинается с подготовки: получить исходники и установить нужную версию Python.

name: Check

on:
  push:
    branches: [master]
    paths: ["**.py"]
  pull_request:
    branches: [master]

jobs:
  check:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        python-version: ["3.10", "3.11", "3.12"]
    steps:
      - name: Checkout sources
        uses: actions/checkout@v7

      - name: Set up Python
        uses: actions/setup-python@v7
        with:
          python-version: ${{ matrix.python-version }}

Блок strategy.matrix задаёт матричную сборку. Один и тот же набор шагов выполняется на нескольких версиях Python, и если библиотека перестала работать на 3.12, но работает на 3.10, это выясняется сразу. Для библиотеки, передаваемой незнакомым людям, такая проверка обязательна: разработчик не управляет тем, какой Python установлен у пользователя.

Анализаторов два, поскольку обнаруживают они разное. flake8 следит за стилем и очевидными ошибками, pylint анализирует глубже и сообщает о сомнительных конструкциях; в новых проектах первый обычно заменяют на ruff. Шаги продолжают список steps той же работы:

      - name: Install deps
        run: |
          python -m pip install --upgrade flake8 pylint
          python -m pip install -r requirements.txt

      - name: Run flake8
        run: python -m flake8 redpic tests setup.py

      - name: Run pylint
        run: python -m pylint redpic tests setup.py

Проверяется не только код библиотеки, но и tests с setup.py. Тесты также являются кодом, и приходят в негодность они не реже основного.

Второй файл, test.yml, устроен так же, но вместо анализаторов устанавливает pytest и выполняет тесты:

      - name: Run functional test
        run: python -m pytest tests/functional/src

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

Третий файл, release.yml, выпускает релиз. Он запускается только на поставленный автором тег версии. Первая работа собирает пакет, отправляет его в PyPI, где он становится доступен по pip install redpic, и прикладывает архив исходников к релизу на GitHub:

name: Release

on:
  push:
    tags: ["*.*.*"]

jobs:
  library:
    runs-on: ubuntu-latest
    permissions:
      contents: write  # создание релиза на GitHub
      id-token: write  # публикация в PyPI без токена
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-python@v7
        with:
          python-version: "3.12"

      - name: Build distributions
        run: |
          python -m pip install --upgrade build twine
          python -m build
          python -m twine check --strict dist/*

      - name: Publish distribution to PyPI
        uses: pypa/gh-action-pypi-publish@release/v1

      - name: Upload Release Asset (sdist) to GitHub
        uses: softprops/action-gh-release@v3
        with:
          files: dist/*.tar.gz

Блок permissions перечисляет права, которые получает работа; без него токен работы в новых репозиториях может только читать. Право id-token: write нужно для доверенной публикации (Trusted Publishing): PyPI принимает пакет от конвейера, заранее зарегистрированного на сайте, и токен PyPI в репозитории не хранится.

Ещё две работы того же файла собирают руководство и документацию. PDF-версия руководства прикладывается к релизу, а документация, собранная Sphinx из исходников, публикуется на GitHub Pages:

  manual:
    needs: library
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v7

      - name: Compile LaTeX document
        uses: xu-cheng/latex-action@v4
        with:
          root_file: main.tex
          working_directory: manual/

      - name: Upload Release Asset (pdf) to GitHub
        uses: softprops/action-gh-release@v3
        with:
          files: manual/main.pdf

  docs:
    needs: library
    runs-on: ubuntu-latest
    permissions:
      contents: write
    steps:
      - uses: actions/checkout@v7

      - uses: actions/setup-python@v7
        with:
          python-version: "3.12"

      - name: Build docs
        run: |
          python -m pip install -r docs/requirements.txt
          python -m sphinx docs docs/_build/html

      - name: Push documentation to GitHub Pages
        uses: peaceiris/actions-gh-pages@v4
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}
          publish_dir: docs/_build/html

Пароли и токены в конвейере никогда не записываются открытым текстом: они помещаются в хранилище секретов репозитория и подставляются по имени, например ${{ secrets.PYPI_API_TOKEN }}, если пакет публикуется по токену. Исключение составляет secrets.GITHUB_TOKEN: этот токен GitHub выдаёт каждой работе сам, с правами из блока permissions. Секрет, закоммиченный в репозиторий, считается скомпрометированным навсегда: история git хранит всё, и удаление следующим коммитом ничего не исправляет.

Каждое чужое действие — код, выполняемый в конвейере разработчика с доступом к его секретам. Неизменяемой ссылкой на действие служит только полный хеш коммита: тег, как и ветку, может перенести на другой коммит любой, получивший доступ к репозиторию действия (так в марте 2025 года были подменены теги действия tj-actions/changed-files). Мажорные теги вида @v7 переносятся на каждый новый выпуск по замыслу; в примере для краткости указаны именно они, а в рабочем конвейере действия сторонних авторов надёжнее закреплять полным хешем коммита с комментарием о версии, обновлять который помогает Dependabot. Запись вида @master означает «взять из чужой ветки то, что там находится сегодня». @release/v1 в примере — также ветка, однако PyPA поддерживает её под стабильные выпуски и сама рекомендует такую запись.

Одного тега в git достаточно, чтобы появилась новая версия библиотеки, устанавливаемая через pip, с собранной документацией и PDF-руководством, приложенным к релизу. Ни одного действия вручную, а следовательно, ни одной возможности пропустить шаг.

Это главный аргумент в пользу CI/CD в науке. Релиз, собираемый вручную, рано или поздно окажется собран не из того коммита, без одного теста или с забытым файлом, и обнаружится это через полгода, когда результат уже опубликован.

Задание. Выступить в роли рецензента: «Ревью чужого кода».

Сопровождение

Работающую систему необходимо наблюдать: собирать метрики и логи, следить за ними и вовремя замечать сигналы о неполадках. Метрики показывают задержки, долю ошибок и нагрузку, логи позволяют восстановить, что происходило перед сбоем, а трассировки — проследить запрос через несколько сервисов. Вместе их называют наблюдаемостью (observability); подробно она рассмотрена в главе «Наблюдаемость», а практика эксплуатации — в книге Google «Site Reliability Engineering» [23].

В зрелых командах вокруг этого выстраивается набор практик: назначенные дежурства с порядком реагирования на инциденты; разбор каждого сбоя без поиска виноватых, с поиском причин и мер, исключающих повторение; feature-флаги для быстрого выключения проблемной функции; регулярные учения на случай отказов. Chaos engineering — намеренное внесение отказов в работающую систему ради проверки того, что она их переживает: выяснять, что план не работает, лучше в контролируемых условиях, чем во время аварии.

Для лабораторного сервиса минимум следующий: программа ведёт журнал, перезапускается после сбоя, а об отказе кто-то узнаёт раньше, чем это обнаружат пользователи. Перезапуск обеспечивает, например, политика контейнера docker run --restart on-failure. Причину отказа он не устраняет: о перезапуске должен узнать человек, а причину разбирают по журналу.

Завершение жизненного цикла

Рано или поздно программу перестают поддерживать: её заменяет новая система, исчезает задача или некому её сопровождать. Об этом объявляют заранее, называя сроки, дают пользователям время и путь перехода на замену, а данные выгружают в формате, переживающем сам сервис. Инфраструктуру отключают, не оставляя забытых серверов и открытых портов.

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

Резюме

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

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

Требования к коду на Python

Требования к коду на Python, действующие в этой книге, рекомендуется соблюдать и в собственных проектах.

Слайды к главе. Требования к коду и их автоматическая проверка (линтер, форматтер, хук pre-commit) изложены также в лекции «Жизненный цикл ПО» с демонстрациями в терминале; слайды лекции доступны на сайте книги и в PDF.

Требования следующие:

• Строгое соответствие PEP 8.
• Длина строки — 79 символов.
• Импорты корректно отсортированы, неиспользуемых импортов нет.
• Отступы делаются в 4 пробела.
• Переносы строк выполнены с правильными отступами.
• Обратные слеши для переносов не используются.
• Консистентность (одинаковые кавычки, одинаковые способы решения одинаковых задач).
• Отсутствие закомментированного кода и стандартных комментариев-заглушек (# Create your views here. и т. п.).
• Комментарии к функциям оформлены как docstring в соответствии с Docstring Conventions, то есть начинаются с заглавной буквы, заканчиваются точкой и содержат описание того, что делает функция.
• Комментарии к коду краткие и информативные.
• Длинные куски кода логически разделены пустыми строками, как абзацы в тексте.
• Нет лишних операций.
• Нет лишних else (если в if происходит return/raise); используется guard block.
• В репозитории нет лишних файлов наподобие __pycache__ и .vscode, попадающих туда по невнимательности.
• Исполняемый код в .py-файлах закрыт конструкцией if __name__ == "__main__":.
• Для неизменяемых последовательностей данных предпочтительны кортежи, а не списки.
• В f-строках используется только подстановка переменных, без логических и арифметических операций, вызовов функций и прочей динамики, мешающей читать шаблон.
• Имена переменных, выбранные по смыслу, записаны по-английски; однобуквенных имён нет (кроме счётчиков в коротких циклах и общепринятых математических обозначений).
• Функции и методы названы глаголами или глагольными фразами (get_data, compute_energy), а классы существительными (Particle, FieldSolver); функция-формула, возвращающая величину, допускает имя этой величины, как mean и exp в NumPy.
• Магические числа вынесены в именованные константы.

Большинство перечисленных пунктов проверяются автоматически линтерами и форматтерами ruff, flake8, black, isort, работающими в редакторе. Если они настроены в редакторе и в CI, следить за этими правилами вручную почти не требуется. black и ruff format по умолчанию форматируют по 88 символов, а не по 79, поэтому длину необходимо задать явно в pyproject.toml ([tool.black] line-length = 79, [tool.ruff] line-length = 79), иначе форматтер и линтер будут предъявлять к коду противоречащие требования. Набор правил линтера также задают явно ([tool.ruff.lint] select = [...]): правила по умолчанию меняются от версии к версии, и в ruff 0.16 из них исключены, например, проверки сравнения с None и импорта со звёздочкой. Проверки удобно запускать хуком pre-commit перед каждым коммитом, а в CI — на каждый push.

Принципы проектирования