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

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

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

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

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

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

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

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

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

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

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

• Пользоваться ИИ-помощниками и контролем версий. Языковые модели с пониманием того, где они помогают, а где вредят; 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

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

Глава выстроена по нарастающей: сначала рассматривается обустройство рабочего места, затем основы командной строки, далее утилиты, необходимые каждый день, и, наконец, диагностика в ситуации, когда система работает не так, как ожидалось. Запоминать всё подряд не требуется: достаточно знать, что подходящий инструмент существует, а подробности всегда приведены в 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 решают эту проблему: сессия, отвязанная от терминала, продолжает работать на сервере, а пользователь подключается к ней и отключается в любой момент, в том числе с другой машины.

• 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) описывает то же ожидание, но аппаратного ввода-вывода, диска или сети. Оно не прерывается сигналом, включая 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, набора библиотек, системных пакетов и десятка настроек, отсутствующих в репозитории. На этом стыке нарушается воспроизводимость чужих результатов.

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

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

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

Docker упаковывает приложение вместе со всем его окружением, с интерпретатором, библиотеками, системными зависимостями и настройками, в единый образ. Собранный образ запускается одинаково на ноутбуке автора, на машине коллеги и на сервере в лаборатории.

Контейнеры 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, однако образ под этим тегом сегодня и через год окажется разным, а требуется воспроизводимость.

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

# запустить контейнер и выполнить в нём одну команду
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-вариант без лишних пакетов.
# Всегда фиксируй версию — это фундамент воспроизводимости.
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                      # сначала стартует база, потом приложение

  db:
    image: postgres:16          # готовый образ с Docker Hub
    environment:
      POSTGRES_USER: physicist
      POSTGRES_PASSWORD: secret
      POSTGRES_DB: measurements
    volumes:
      - pgdata:/var/lib/postgresql/data   # именованный том: данные переживут контейнер

volumes:
  pgdata:

Compose автоматически создаёт общую сеть, в которой контейнеры видят друг друга по именам сервисов, объявленным в файле, и приложение подключается к базе по адресу db:5432, без IP. Основные команды:

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 на порт бэкенда с хоста отвечать не должен.

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

Контейнер является ответом рецензенту, требующему воспроизвести результаты. Всё чаще к статье прикладывают не только код, но и собранный образ или хотя бы Dockerfile, помещённый в репозиторий. Одной команды docker run достаточно, чтобы читатель получил те же графики из тех же данных, с точностью до версий всех задействованных библиотек. На суперкомпьютерах Docker обычно запрещён из-за демона, работающего с правами root. Там используется Apptainer (бывший Singularity), контейнерная система, спроектированная для HPC, которая работает без root-прав, совместима с MPI и GPU и позволяет напрямую конвертировать Docker-образы. Поэтому образ, собранный для ноутбука, почти без изменений запускается и на кластере.

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

• 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 рассматривается в главе, посвящённой асинхронности.

Итераторы

Любая коллекция, встроенная в язык (списки, словари, множества, строки, файлы), является итерируемой.

Итератор представляет собой объект с методом __next__, который при каждом вызове возвращает следующий элемент, а по исчерпании элементов возбуждает StopIteration. Итерируемый объект обладает методом __iter__, возвращающим итератор. Список является итерируемым, но не итератором, поэтому по нему можно пройти дважды, а по итератору — лишь один раз.

Рассмотрим собственный аналог range, в котором обе роли разделены явно. Контейнер Range способен только выдать итератор, а сам обход осуществляется классом RangeIterator.

class Range:
    def __init__(self, stop_value: int):
        self.stop_value = stop_value - 1

    def __iter__(self):
        return RangeIterator(self)

class RangeIterator:
    def __init__(self, container):
        self.container = container
        self.current = -1          # состояние обхода живёт здесь

    def __iter__(self):
        return self                # итератор обязан быть итерируемым

    def __next__(self):
        if self.current < self.container.stop_value:
            self.current += 1
            return self.current
        raise StopIteration

Поле current хранится в итераторе, а не в контейнере, поэтому каждый новый for начинает счёт заново, а по одному объекту Range(5) можно пройти произвольное число раз. Если поместить счётчик в контейнер, второй проход окажется пустым. Без метода __iter__ у самого итератора объект не является итерируемым, и цикл for по нему невозможен.

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

class Range2:
    def __init__(self, stop_value: int):
        self.current = -1
        self.stop_value = stop_value - 1
    
    def __iter__(self):
        return self
    
    def __next__(self):
        if self.current < self.stop_value:
            self.current += 1
            return self.current
        raise StopIteration

Обычный цикл for получает итератор через iter, вызывает next в цикле и перехватывает StopIteration, чтобы остановиться.

iterable = Range2(5)
iterator = iter(iterable)

while True:
    try:
        value = next(iterator)
        print(value)
    except StopIteration:
        break

Генераторы

Генераторы работают на принципе запоминания контекста, сохраняемого ключевым словом yield.

Написание двух классов ради простого перебора является избыточным. Функция с yield при вызове не выполняет тело, а возвращает генератор. Тело начинает выполняться при next, доходит до ближайшего yield, отдаёт значение и приостанавливается, сохранив все локальные переменные и место остановки.

В примере ниже первые два вызова возвращают значения, а третий доходит до return и возбуждает StopIteration, поместив в него возвращённое значение.

def simple_generator():
    yield 1
    yield 2
    return 3

gen = simple_generator()
print(next(gen))  # 1
print(next(gen))  # 2
print(next(gen))  # StopIteration: 3

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

gen_exp = (x for x in range(100000))
print(gen_exp)  # <generator object <genexpr> at 0x...>

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

def read_events(path):
    """Отдаёт события журнала по одному, не читая файл целиком."""
    with open(path) as f:
        for line in f:
            if not line.strip() or line.startswith('#'):
                continue           # пустые строки и комментарии пропускаем
            t, channel, value = line.split()
            yield float(t), channel, float(value)

for t, channel, value in read_events('run042.log'):
    if channel == 'BPM01':
        print(t, value)

Обратный случай — бесконечная последовательность. Генератор вычисляет значения, пока они запрашиваются, а границу устанавливает читающая сторона: itertools.islice берёт первые несколько значений и освобождает генератор.

import itertools

def clock(dt):
    """Бесконечная последовательность моментов времени с шагом dt."""
    t = 0.0
    while True:
        yield t
        t += dt

for t in itertools.islice(clock(0.02), 5):
    print(round(t, 3))  # 0.0, 0.02, 0.04, 0.06, 0.08 — по одному в строке

Когда генератор лишь передаёт элементы другого источника, цикл с yield записывается короче через yield from. Это не только синтаксическое упрощение: конструкция пробрасывает во вложенный генератор всё, что передаётся через send и throw, а наружу отдаёт его return, что необходимо при вложенных генераторах.

numbers = [1, 2, 3]

# Стандартный подход
def func():
    for item in numbers:
        yield item

# Упрощенный подход
def func():
    yield from numbers

Корутины

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

Генератор только отдаёт значения наружу, а корутина способна и принимать их. Выражение deposit = (yield) приостанавливает функцию и ожидает, пока извне будет вызван send. Таким образом, получается диалог с функцией, сохраняющей между запросами своё состояние.

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

import math
from collections.abc import Generator

def cash_return_coro(percent: float,
                     years: int) -> Generator[float | None, float, None]:
    value = math.pow(1 + percent / 100, years)
    while True:
        try:
            deposit = (yield)
            yield round(deposit * value, 2)
        except GeneratorExit:
            print('Выход из корутины')
            raise

# Использование
coro = cash_return_coro(5, 5)
next(coro)
values = [1000, 2000, 5000, 10000, 100000]
for item in values:
    print(coro.send(item))
    next(coro)
coro.close()

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

Дальнейшее изучение

Таким образом, итератор отдаёт элементы по одному, генератор приостанавливает функцию на yield и продолжает с места, запомненного при остановке, а корутина способна ещё и принимать значения через send().

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

Декораторы и модуль 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 не является обязательным. Модуль, составленный из десятка функций, представляет собой полноценную программу, и оборачивать её в класс только ради класса не требуется. Классы применяются тогда, когда у данных появляется состояние, которое необходимо поддерживать согласованным, или когда одну и ту же операцию требуется выполнять по-разному для объектов разного вида, обрабатываемых единым кодом.

Базовые понятия

Определение класса

Метод __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

Название «конструктор», закрепившееся за __init__, строго говоря неверно, поскольку объект к этому моменту уже создан. Создаёт его метод __new__, а __init__ только заполняет заготовку, полученную от него. Разница проявляется при наследовании от неизменяемого типа наподобие int или tuple, у которого изменять уже нечего, и вся работа переносится в __new__.

Специфика Python

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

Модификаторов доступа наподобие private и protected в Python нет, вместо них действует соглашение об именовании.

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

Только за двойным подчёркиванием стоит механизм, встроенный в язык. Интерпретатор переписывает имя, помеченное таким образом, добавляя к нему имя класса, вследствие чего __private внутри класса Counter превращается в _Counter__private. Механизм предназначен для предотвращения коллизий, а не для сокрытия данных, так что базовый класс и подкласс, объявив по атрибуту __cache, не столкнутся. Доступ к «приватному» атрибуту при этом сохраняется через полное имя.

Атрибуты классов и экземпляров

Атрибуты в 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 создаётся один раз, при чтении определения класса. Если бы он был задуман как список, заведённый у каждого счётчика отдельно, все экземпляры разделяли бы один. Здесь общий список необходим, однако при объявлении изменяемого атрибута класса следует проверять, должен ли он быть общим.

Словарь атрибутов

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

noop = Noop()
noop.some_attribute = 42
print(noop.__dict__)  # {'some_attribute': 42}
print(vars(noop))     # альтернативный способ

# Динамическое управление атрибутами
noop.__dict__["dynamic_attr"] = "value"

Встроенная vars() с аргументом возвращает __dict__ объекта, а без аргументов — словарь текущего локального пространства имён. Прямая запись в __dict__ требуется редко, но оказывается полезной при имени атрибута, вычисляемом во время выполнения.

__slots__ для оптимизации

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

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

class Noop:
    __slots__ = ["some_attribute"]  # фиксирует набор атрибутов
    
    def __init__(self):
        self.some_attribute = 42

# Экономит память, но запрещает добавление новых атрибутов

На объекте с парой полей это экономит около 40 % памяти: 96 байт на экземпляр без слотов против 56 со слотами. Скорость доступа не меняется: измерение, приведённое в главе про оптимизацию, показывает, что разница находится в пределах погрешности. Взамен теряется динамика: добавить атрибут, отсутствующий в списке, не удастся, будет получено AttributeError, и перестают работать слабые ссылки, если __weakref__ не указан в слотах явно. Начинать с __slots__ нецелесообразно; его добавляют тогда, когда профилировщик покажет, что память расходуется именно здесь.

Методы

Связанные и несвязанные методы

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

class SomeClass:
    def do_something(self):
        print("Doing something.")

# Несвязанный метод
method = SomeClass.do_something
instance = SomeClass()
method(instance)  # нужно явно передать экземпляр

# Связанный метод
bound_method = instance.do_something
bound_method()  # self уже привязан

Связанный метод представляет собой полноценный объект: его помещают в переменную, передают в map или регистрируют как обработчик события, а ссылку на свой экземпляр он хранит в себе. В Python 2 обращение через класс давало особый тип, проверявший тип первого аргумента и не пропускавший посторонние объекты; в Python 3 это обычная функция.

Свойства (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):
        assert all(p > 0 for p in new_params)
        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 в сеттере. Интерфейс не меняется, а поведение за ним может меняться произвольно. Внутренне свойства построены на дескрипторах, рассматриваемых в конце главы.

Наследование

Базовое наследование

Подкласс получает всё, объявленное у родителя, и добавляет своё. Если метода нет у подкласса, интерпретатор поднимается по цепочке наследования и ищет его выше. 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

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

Перегрузка методов и 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)  # вызов родительского конструктора

Запись Counter.__init__(self, initial) вместо super() является распространённой ошибкой, и разница проявится при множественном наследовании. super() обращается не к родителю, а к следующему классу в порядке разрешения методов, зависящем от того, как класс использовался в дальнейшем. Имя родителя, указанное явно, эту цепочку разрывает.

Множественное наследование

Порядок, в котором интерпретатор перебирает классы в поисках метода, называется 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 откажется создавать класс.

Классы-примеси

Примесью (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. Аналогичным образом устроена значительная часть Django.

Декораторы классов

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

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(id(Noop()) == id(Noop()))  # True

Декораторы классов появились в Python 3.0 и потеснили метаклассы: многое, ради чего раньше писался метакласс, теперь выполняется одной функцией. Наиболее известным примером является @dataclass, добавляющий классу __init__, __repr__ и __eq__ по полям, объявленным в теле.

Магические методы

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

Управление атрибутами

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

class Noop:
    def __getattr__(self, name):
        # Вызывается при доступе к несуществующему атрибуту
        return f"Attribute {name} doesn't exist"
    
    def __setattr__(self, name, value):
        # Вызывается при установке любого атрибута
        super().__setattr__(name, value)
    
    def __delattr__(self, name):
        # Вызывается при удалении атрибута
        super().__delattr__(name)

noop = Noop()
print(noop.non_existent)  # "Attribute non_existent doesn't exist"

Обращение к super() внутри __setattr__ обязательно: self.name = value вызовет метод рекурсивно. По той же причине не рекомендуется переопределять __getattribute__, перехватывающий доступ ко всем атрибутам, а не только к отсутствующим.

Операторы сравнения

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

import functools

@functools.total_ordering
class Counter:
    def __init__(self, value):
        self.value = value
    
    def __eq__(self, other):
        return self.value == other.value
    
    def __lt__(self, other):
        return self.value < other.value

c1, c2 = Counter(1), Counter(2)
print(c1 < c2)   # True
print(c1 >= c2)  # False (автоматически из __lt__ и __eq__)

Определение __eq__ отключает хеширование: объект не попадёт ни в множество, ни в ключи словаря. Причина та же, что у изменяемых коллекций: равные объекты обязаны иметь равные хеши, а вычислять их самостоятельно Python не берётся. Если объект должен оставаться хешируемым, __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…>.

Другие полезные магические методы

__call__ делает экземпляр вызываемым, и на этом основаны декораторы, реализованные классами, и объекты, хранящие настройки между вызовами. __bool__ задаёт, что объект означает в условии if; без него Python обращается к __len__, и объект нулевой длины оказывается ложным, а объект без обоих методов истинен всегда. __hash__ определяет, как объект попадает в множества и словари.

class Identity:
    def __call__(self, x):
        # Позволяет вызывать экземпляры как функции
        return x
    
    def __bool__(self):
        # Определяет поведение в булевом контексте
        return True
    
    def __hash__(self):
        # Используется для хеширования в словарях и множествах
        return hash(id(self))

identity = Identity()
print(identity(42))  # 42

__call__ стирает границу между функцией и объектом: вызов identity(42) выглядит как обычный, хотя слева стоит экземпляр класса. Поэтому всюду, где документация требует передать функцию, подходит любой объект с __call__.

Дескрипторы

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

Базовый дескриптор

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

class NonNegative:
    def __get__(self, instance, owner):
        # magically_get_value
        pass
    
    def __set__(self, instance, value):
        assert value >= 0, "non-negative value required"
        # magically_set_value
    
    def __delete__(self, instance):
        # magically_delete_value
        pass

class VerySafe:
    x = NonNegative()
    y = NonNegative()

very_safe = VerySafe()
very_safe.x = 42      # OK
very_safe.x = -42     # AssertionError

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

Через дескрипторы в Python реализовано почти всё, связанное с атрибутами: и @property, и @staticmethod, и @classmethod, и сама привязка методов к экземпляру. Знание протокола напрямую требуется нечасто, но он объясняет, почему функция, хранящаяся в классе, при обращении через экземпляр оказывается связанным методом.

Хранение данных в дескрипторах

Хранить значение в самом дескрипторе нельзя: он один на весь класс, а экземпляров много, и значения, записанные ими, затирали бы друг друга; правильным местом является словарь самого экземпляра.

class Proxy:
    def __init__(self, label):
        self.label = label
    
    def __get__(self, instance, owner):
        return instance.__dict__[self.label]
    
    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

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

Имя поля приходится дублировать в Proxy("attr"); начиная с Python 3.6 от этого избавляет метод __set_name__, вызываемый интерпретатором при создании класса и сообщающий дескриптору имя, под которым тот записан.

Встроенные дескрипторы

Три реализации ниже сокращены, но верно передают устройство, заложенное в интерпретатор.

# @property реализован через дескрипторы
class property:
    def __init__(self, get=None, set=None, delete=None):
        self._get = get
        self._set = set
        self._delete = delete
    
    def __get__(self, instance, owner):
        if self._get is None:
            raise AttributeError("unreadable attribute")
        return self._get(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))

Вся разница между @staticmethod и @classmethod заключается в их __get__. Статический метод возвращает исходную функцию без привязки, поэтому self в нём отсутствует. Метод класса привязывает функцию к классу, и первым аргументом приходит сам класс. Аналогично, только к экземпляру, привязываются обычные методы.

Метаклассы

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

Требуются они редко: почти всё, ради чего раньше писались метаклассы, сегодня выполняется декоратором, применённым к классу, или методом __init_subclass__. Однако на метаклассах построены ORM и системы валидации данных, где поля, объявленные в классе, описываются декларативно.

Базовый метакласс

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

from collections import OrderedDict

class Meta(type):
    def __new__(metacls, name, bases, clsdict):
        print(f"Creating class {name}")
        cls = super().__new__(metacls, name, bases, clsdict)
        return cls
    
    @classmethod
    def __prepare__(metacls, name, bases):
        # Может вернуть нестандартный mapping для clsdict
        return OrderedDict()

class Something(metaclass=Meta):
    attr = "foo"
    other_attr = "bar"

Второй метод, __prepare__, выбирает, в чём накапливать тело класса, пока оно читается. Возвращённый им словарь и попадёт затем в clsdict, а значит, подставив сюда собственный тип отображения, можно запомнить порядок объявления атрибутов или проверять на месте каждое выполненное присваивание. Так и работают ORM, где порядок полей определяет порядок колонок, созданных в таблице. Начиная с версии 3.7 тело класса и без __prepare__ накапливается в обычном dict, сохраняющем порядок вставки, так что OrderedDict здесь требуется не ради порядка, а ради move_to_end и прочих возможностей, отсутствующих у простого словаря.

Создание классов через type()

Оператор class является удобной записью вызова type с тремя аргументами: именем, родителями и словарём атрибутов.

# Эквивалентно class Something: attr = 42
name, bases, attrs = "Something", (), {"attr": 42}
Something = type(name, bases, attrs)

some = Something()
print(some.attr)  # 42

Модуль abc для абстрактных базовых классов

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

import abc

class Iterable(metaclass=abc.ABCMeta):
    @abc.abstractmethod
    def __iter__(self):
        pass

class Something(Iterable):
    pass

# Something()  # TypeError: Can't instantiate abstract class

Отдельной конструкции interface, как в Java, в Python нет: интерфейсы описываются обычными классами с заданным метаклассом ABCMeta. Проще всего наследоваться от готового abc.ABC, выполняющего то же самое.

Модуль collections.abc

Абстрактные классы для самих коллекций уже написаны и находятся в collections.abc, и это те же Container, Iterable, Sequence и Mapping, рассмотренные в главе про коллекции. Наследование даёт две выгоды: интерпретатор сначала проверит, что реализовано всё обязательное, а затем сам добавит остальное. Реализация у MutableMapping пяти методов даёт готовые get, pop, setdefault, update, items, keys и values.

from collections import deque
from collections.abc import MutableMapping

class MemorizingDict(MutableMapping):
    def __init__(self, *args, **kwargs):
        self._data = dict(*args, **kwargs)
        self._history = deque(maxlen=10)
    
    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

Написано пять обязательных методов и один собственный, а в результате получается полноценный словарь, запоминающий десять последних записанных ключей. Он пройдёт isinstance(d, MutableMapping) и будет принят любой библиотекой, ожидающей отображение.

Заключение

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

В повседневной работе достаточно немногого:

• Класс необходим там, где есть состояние, которое требуется поддерживать согласованным. Если состояния нет, достаточно функции.
• Атрибут остаётся атрибутом; свойство добавляется тогда, когда за ним потребовалась логика.
• __repr__ определяется сразу.
• В переопределённых методах родитель вызывается через super(), а не по имени класса.
• Прежде чем строить иерархию наследования, целесообразно проверить, не решается ли задача композицией: объект, содержащий другой объект, почти всегда проще объекта, унаследованного от него.

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

Роль алгоритмов в работе физика

Устройство Python было рассмотрено в предыдущем разделе, однако за ним стоит фундамент, переживающий и смену языка, и смену моды, — базовые знания computer science.

Алгоритмическая грамотность представляет собой умение заранее оценить, выполним ли расчёт за приемлемое время. Миллион событий детектора, обрабатываемый алгоритмом за \(O(n^2)\), приводит к триллиону операций, и NumPy, написанный на C, в этом случае не поможет. Удачно выбранная структура данных сокращает время счёта на порядки, причём чаще, чем низкоуровневая оптимизация.

В настоящем разделе рассматриваются:

• Введение в алгоритмы, где вводится понятие алгоритма и разбирается оценка сложности, не привязанная к конкретной машине;
• Основные структуры данных, где разобраны массивы, списки, стеки, очереди и деки и показано, как они представлены в Python;
• Рекурсия и сортировки, где разобраны сортировка слиянием, быстрая сортировка и сортировка подсчётом;
• Хеш-функции, объясняющие, почему словарь ищет за \(O(1)\) и как устроены хеш-таблицы;
• Деревья, иерархические структуры, дополненные деревьями поиска и кучами;
• Графы, их представления, обходы и классические задачи, решаемые обходом.

Материал построен на разборе задач: сначала излагается необходимая теория, затем приводятся задачи с решениями, расписанными на Python. Рекомендуется сперва попытаться решить задачу самостоятельно и только после этого обращаться к разбору.

Введение в алгоритмы

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

Линейный поиск

Дан массив целых чисел длины \(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

Линейный vs Бинарный поиск

Запустим оба поиска на одних и тех же данных и рассмотрим, как меняется измеренное время работы с ростом массива.

Будем искать элемент, стоящий в самом конце, что даёт худший случай для линейного поиска:

При увеличении массива в 10 раз линейный поиск замедляется также примерно вдесятеро: 11 мкс, 122 мкс, 1.3 мс, 12 мс. Бинарный же поиск за пять порядков роста замедлился всего впятеро, с 0.14 до 0.69 мкс.

Именно так выглядит разница между \(O(n)\) и \(O(\log n)\) на практике. На миллионе элементов бинарный поиск быстрее линейного почти в восемнадцать тысяч раз, и чем больше накопленных данных, тем этот разрыв шире.

Измерение может быть воспроизведено самостоятельно:

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-нотация — запись, показывающая, как растёт число операций с ростом входных данных. В ней не учитываются константы и коэффициенты, то есть если в алгоритме совершается \(5\cdot n+3\) операций, его сложность будет \(O(n)\). В асимптотической оценке отброшены и значения констант при \(n\). Отброшенные константы также имеют значение, однако изменить применимость алгоритма на практике они не могут.

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

• Квадратичная зависимость \(O(n^2)\).
• Кубическая зависимость \(O(n^3)\).
• Экспоненциальная зависимость \(O(2^n)\).
• Константная зависимость \(O(1)\). Встречаются и случаи, когда время работы алгоритма не зависит от размера входных данных, а число выполняемых операций остаётся постоянным.

Оценка времени исполнения

Современный процессор выполняет около 2.5 миллиардов действий, называемых «инструкциями», в секунду, или, иначе говоря, «тактовая частота процессора = 2.5 ГГц».

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

Предположим, что обработка каждой итерации цикла занимает один такт процессора. Возьмём \(10^9\) итераций, тогда:

$$ t = \frac{10^9 [итер] \cdot 1 [\frac{такт}{итер}]}{2.5 \cdot 10^9 [\frac{такт}{с}]} = 0.4 [с] $$

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

Даже при желании узнать константы в оценке временной сложности сделать это не удалось бы: пришлось бы учесть слишком много нюансов. Это ещё одна причина пользоваться 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')

97.01491403579712 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;
}

Каждая итерация цикла состоит из трёх действий: прибавить единицу, проверить условие и переместиться обратно к началу цикла. Три миллиарда команд должны занимать приблизительно секунду, и опыт это подтверждает, но только при оговорённых условиях. При сборке без оптимизации (c++ -O0 loop.cpp) получается примерно секунда. С -O2 компилятор обнаруживает, что i далее нигде не используется, удаляет цикл целиком и печатает почти ноль; чтобы этого не происходило, счётчик объявляют volatile. Это классическая ловушка микробенчмарков на компилируемых языках. Аналогичная программа на Python выполняется около 100 секунд, то есть в сто раз медленнее. Так происходит, поскольку код, написанный на языках низкого уровня, почти один к одному транслируется в инструкции процессору.

Пространственная сложность алгоритма

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

Если программе не хватает оперативной памяти, она пытается использовать файл подкачки, или 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 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) \)
• Деление пополам, повторяющееся на каждом шаге, означает логарифмическую сложность
• Полный перебор, охватывающий все комбинации, означает экспоненциальную сложность

Алгоритмически неразрешимые проблемы

Проблема останова

Существуют задачи, для которых доказано, что решающего их алгоритма не существует; самая известная из них формулируется следующим образом. Пусть даны алгоритм \(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):
    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. Алгоритм можно ускорить. Для каждого простого числа \(p\) начнём отмечать составными числа начиная с \(p^2\): всё, лежащее ниже, к этому моменту уже рассмотрено. Получится следующий код:

def eratosthenes_effective(n):
    numbers = list(range(n + 1))
    numbers[0] = numbers[1] = False
    for num in range(2, n):
        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))\). Доказательство опирается на нетривиальные факты из теории чисел.

Существует метод решения задачи нахождения всех простых чисел, не превосходящих \(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])

Резюме

• От алгоритма требуется шесть свойств: дискретность, детерминированность, понятность, завершаемость, массовость и результативность.
• O-нотация описывает, как растёт время работы с ростом объёма данных, отбрасывая константы. Отброшенные множители зависят от процессора и компилятора, характер роста — нет.
• На миллионе элементов \(O(n)\) обходится в двенадцать миллисекунд, тогда как \(O(\log n)\) — меньше чем в микросекунду. На больших данных выбранный алгоритм значит больше, чем любая микрооптимизация.
• Пространственная сложность оценивается аналогично, и между временем и занятой памятью почти всегда приходится выбирать.
• Прежде чем оптимизировать, необходимо измерить. Оценка сложности показывает, чего следует ожидать, но реальное время определяется измерением.

Задание. Требуется решить задачи и оценить сложность полученных решений: «Решение задач на Python и анализ сложности».

Основные структуры данных

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

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

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

Оперативная память и представление данных

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

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

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

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

Оперативной памяти в компьютере на порядки меньше, чем места на диске, — десятки гигабайт против терабайтов, — и записанные данные исчезают из неё сразу после завершения работы программы. Поэтому она не подходит для длительного хранения информации, зато работает в сотни раз быстрее 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 бита, один из которых кодирует знак. Оставшийся 31 бит позволяет закодировать \(2^{31} = 2;147;483;648\) чисел. Число «ноль» также занимает один из кодов, поэтому положительных чисел остаётся на одно меньше, чем отрицательных.

Если числа не превышают по модулю два миллиарда, этого типа достаточно. Всего значений около четырёх миллиардов, но половина из них отрицательные. Если точно известно, что переменная не может быть отрицательной, подходит тип беззнаковых целых unsigned int, хранящий числа от 0 до 4 294 967 295.

Вещественные (то есть дробные) числа чаще всего кодируются типом double, «числами с плавающей точкой», занимающими 8 байт. Восьми байт хватает и на очень большие числа, такие как \(\pm10^{308}\), и на близкие к нулю, например \(\pm10^{-308}\).

Диапазон, однако, не то же самое, что точность. Под мантиссу, цифровую часть числа, из восьми байт отведено 53 бита, что соответствует примерно шестнадцати значащим десятичным цифрам; всё, что за них не поместилось, отбрасывается округлением. Наименьшая добавка, которую единица ещё различает, называется машинным эпсилон и равна примерно \(2.2\cdot10^{-16}\), причём шаг между соседними представимыми числами не постоянен, а растёт вместе с самим числом, оставаясь относительным. Отсюда 0.1 + 0.2 != 0.3: ни одна из этих дробей в двоичной записи не конечна, и сумма отклоняется от ответа на последние биты. Отсюда же следует и потеря точности при вычитании близких величин: старшие цифры, которыми они совпадали, взаимно уничтожаются, и от разности остаётся столько верных цифр, сколько их было в различающейся младшей части.

Составные типы данных

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

Во-первых, потребуется хранить сам текст. Это займёт $$10; строк \cdot (20; \frac{символов}{строка}) \cdot (1;\frac{байт}{символ}) = 200; байт$$ Этого было бы достаточно, если бы строки располагались в памяти друг за другом, но выполнять с ними операции в таком случае было бы сложно.

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

Во многих других языках каждый объект в программе записан в специальную «обёртку», содержащую, помимо данных, вспомогательную информацию. Из-за такой обвязки в Python даже короткие целые числа занимают не 4 байта, а почти 30. Для хранения строки требуется около 40 байт служебных данных, а для хранения массива и того больше. Объекты в таких языках ведут себя как строки из примера выше: они могут находиться в произвольном месте памяти, и любое обращение к ним осуществляется по сохранённому адресу.

Подсчитаем, сколько памяти расходует массив, собранный из 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) байт занимает массив
                               # с десятью элементами.
                               # сами данные хранятся отдельно
                               # и добавляют 280 = (28 * 10) байт

56 байт уходит на сам массив, далее по 8 байт на адрес каждого элемента и ещё по 28 байт на каждое записанное число. Итого массив из десяти чисел в Python занимает 56 + (8 + 28) * 10 байт = 416 байт против 40 байт в C++.

Освобождение памяти

Если программа перестала пользоваться объектом, это ещё не означает, что занимаемая им память освобождена. В языке C++ необходимо следить за тем, чтобы выделенная память освобождалась. Встроенные контейнеры наподобие std::vector сами выделяют память при создании и отдают её обратно, когда переменная, хранящая контейнер, выходит из области видимости.

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

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

Массивы постоянного размера

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

Самый простой тип массивов имеет фиксированный размер и хранит элементы одного и того же типа. Например, в созданный массив из десяти целых чисел нельзя добавить ещё один элемент или записать объект неподходящего типа. Такие массивы встречаются в языке C как int numbers[10], а в C++ как std::array<int, 10> numbers.

С массивами фиксированного размера можно выполнить только две операции:

• получить значение элемента по заданному индексу,
• перезаписать значение по указанному индексу.

Обе операции выполняются за \(O(1)\).

Устройство массива

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

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

Пусть имеется массив numbers из 10 беззнаковых целых чисел, адрес нулевого элемента которого равен 1000. Адрес следующего элемента равен адресу начала плюс размер элемента в байтах. Каждое число занимает по 4 байта, и нулевой элемент займёт байты 1000, 1001, 1002, 1003. Следовательно, элемент с индексом 1 будет записан по адресу 1004.

Сложность вставки и удаления в динамических массивах

Динамические массивы иногда называют «векторами», потому что в C++ они реализуются классом std::vector. В Python динамический массив скрыт за классом list, и, несмотря на название, это не список, а массив.

Сложность вставки в динамический массив

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

Элемент можно вставить в любое место массива; вставка в начало и в конец являются частными случаями. Худший случай — вставка в начало, поскольку все лежащие правее элементы приходится сдвинуть на одну позицию, а это \(O(n)\). Добавление в конец — лучший случай: сдвигать ничего не нужно, и стоимость операции составляет \(O(1)\).

Сложность удаления из динамического массива

При удалении, как и при вставке, приходится сдвигать все элементы, стоящие правее затронутой ячейки: при добавлении — на один вправо, при удалении — на один влево. Стоимость та же: \(O(n)\) при работе с началом массива и \(O(1)\) при работе с концом.

Реаллокация в динамических массивах

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

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

Выделение памяти является долгой операцией, а копирование обходится ещё дороже: пройти придётся по всем записанным элементам, а это \(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\).

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

Связные списки

Элементы массива в памяти компьютера расположены последовательно. Чтобы вставить или удалить элемент из начала массива, требуется \(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')

stack.pop()

Структуры данных: очередь и дек

Очередь, в отличие от стека с его 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 из стандартной библиотеки решает другую задачу, синхронизацию между потоками, и внутри содержит тот же дек.

В стандартной библиотеке дек находится в модуле 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)\) на каждую вставку. Дек устроен как связанные между собой блоки, и добавление к любому его концу не затрагивает уже уложенные элементы.

Замер на 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)\).

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

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) внутри цикла почти наверняка означают, что требуется дек.

Стек вызовов

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

Устройство стека вызовов

Допустим, написана программа на 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() снова 'Гоша'.

Для этого программа хранит локальные переменные на том же стеке: на вершине лежит структура с локальными переменными, аргументами функции и адресом возврата. Проследим, как меняется стек в этом примере.

Работа стека: шаг за шагом

Первая команда программы — вызов 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() больше нет, и управление возвращается по адресу, записанному в её блоке. Блок снимается со стека, а значение переменной 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 другого уровня рекурсии, прочитать или изменить её невозможно.

Чтобы хранить локальные переменные и адрес возврата на каждом уровне рекурсии, потребуется \(O(d)\) памяти на стеке, где d — глубина рекурсии. При вычислении факториала \(n!\) глубина равна n, поэтому приведённая выше функция расходует \(O(n)\) памяти на стеке.

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

Ограничений два. Первое устанавливает сам Python: по умолчанию около тысячи вложенных вызовов, далее RecursionError, а поднять порог можно через sys.setrecursionlimit. Второе — стек операционной системы, обычно 8 МБ; достичь его можно, только сняв первое. Здесь важна версия. До Python 3.10 кадр каждого вызова помещался на стек C, и глубже нескольких десятков тысяч вызовов рекурсию довести было нельзя. С 3.11 кадры питоновских функций переехали в кучу, поэтому чистая рекурсия с поднятым порогом доходит и до миллиона уровней. Однако когда цепочка вызовов уходит через C (например, через __repr__), стек C работает по-прежнему, и переполнение никуда не исчезает (англ. stack overflow). В одних языках при этом возникает исключение «Stack Overflow», в других ошибка «Segmentation Fault».

factorial(10_000)

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

Приёмы против переполнения стека:

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

def factorial(n):
    accumulator = 1
    i = n
    while i > 1:
        accumulator *= i
        i -= 1
    return accumulator

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

Объёмом памяти под стек вызовов можно управлять. В некоторых языках — непосредственно во время работы программы: в Python метод setrecursionlimit() модуля sys параметром limit задаёт максимальную глубину рекурсии; наибольшее значение зависит от платформы и всё равно существенно ограничено. Текущее значение возвращает getrecursionlimit(). В Java и JavaScript размер стека вызовов задаётся настройками виртуальной машины при запуске и во время работы не меняется. Иногда размер стека вызовов можно изменить на уровне операционной системы.

sys.getrecursionlimit()

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

Резюме

Сводная таблица для выбора структуры под задачу:

\(^*\) Амортизированно: изредка происходит реаллокация, но в среднем на каждый добавленный элемент приходится константа.

\(^{**}\) В том виде, в каком список описан выше, с одной только головой: чтобы добавить элемент в конец, приходится пройти весь список. Если хранить ещё и ссылку на хвост, вставка в конец становится \(O(1)\), и так устроены реализации, принятые в стандартных библиотеках.

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

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

Рекурсия и сортировки

Настоящая глава начинается с рекурсии, для многих первого трудного места в программировании, после чего рекурсия применяется к самой изученной задаче информатики — сортировке.

Введение. Примеры задач на рекурсию

Пусть требуется найти файл Kormen.pdf в папке C:\books\, заполненной вложенными подпапками, без поиска, встроенного в файловый менеджер. Возможны два варианта.

Первый — обычный обход списком:

   Обходим папки списком, вручную запоминая, куда ещё не заходили:

   очередь: [C:\books]
   → зашли в C:\books, нашли подпапки: algo, physics
   очередь: [algo, physics]
   → зашли в algo, нашли подпапку: sorting
   очередь: [physics, sorting]
   → зашли в physics … и так далее, пока очередь не опустеет

Второй — тот же поиск, записанный рекурсивно:

   найти(C:\books)
   ├── найти(algo)
   │   └── найти(sorting) ──▶ Kormen.pdf найден!
   ├── найти(physics)
   └── найти(math)

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

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

Рекурсивный и базовый случаи

Любая корректно работающая рекурсия состоит из двух обязательных частей:

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

Рекурсивный случай

Рассмотрим заготовку функции, строящей лестницу из n ступеней:

функция stairs_builder(n):
    построить 1 ступеньку
    print("Осталось построить {n} ступеней.")
    stairs_builder(n - 1)

Вызов функцией самой себя с изменёнными параметрами, stairs_builder(n - 1), и есть рекурсивный случай. Однако программа, написанная таким образом, приведёт к зависанию компьютера: рекурсия, лишённая условия остановки, уйдёт в бесконечный цикл.

На каждом следующем уровне рекурсии число непостроенных ступеней n уменьшается на 1. Но после n = 0 функция, не знающая базового случая, не остановит работу, а вызовется со значением −1, затем с −2 и так далее. При неограниченных ресурсах лестница строилась бы вечно.

Базовый случай

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

Рекурсия в stairs_builder() должна остановиться, когда построено заданное количество ступеней, то есть когда счётчик, уменьшаемый на каждом уровне, дойдёт до n = 0. Это и есть базовый случай.

функция stairs_builder(n):
  if n == 0:
    return
  построить 1 ступеньку
  print("Осталось построить {n} ступеней.")
  stairs_builder(n - 1)

Правильное построение рекурсии

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

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

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

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

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

В большинстве случаев программа, ушедшая в бесконечную рекурсию, не будет работать вечно, а завершится с ошибкой переполнения стека вызовов или с ошибкой сегментации (англ. segmentation fault): каждый вызов, добавленный в стек, расходует память, а она ограничена. Поведение программы зависит и от самого алгоритма, и от используемого компилятора. Подробнее об этом можно прочитать в статье про оптимизацию хвостовой рекурсии (англ. tail call optimization).

Разбор задач. Рекурсивный перебор вариантов

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

Генерация последовательностей из 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

Алгоритмы сортировки. Знакомство

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

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

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

Роль сортировок в решении задач

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

• найти элемент в массиве быстрее чем за \(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)

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

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

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

Сортировка слиянием (англ. 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_2n)\). Глубиной рекурсии называют максимальную глубину стека вызовов, достигаемую за время её работы.

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

Общая сложность алгоритма \(O(n \cdot \log_2 n)\).

Пространственная сложность алгоритма

На каждом уровне рекурсии слиянию требуется \(O(n)\) дополнительной памяти, куда копируются элементы объединяемых блоков в правильном порядке. Если выделять её на каждом уровне заново, суммарно придётся затратить \(O(n\log{n})\) дополнительной памяти.

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

Устойчивость алгоритма

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

Быстрая сортировка

Быстрая сортировка (англ. quick sort) опирается на стратегию «разделяй и властвуй».

Стандартные библиотеки разных языков сделали разный выбор алгоритма сортировки: в C++ std::sort — интроспективная сортировка, то есть быстрая, переходящая в пирамидальную на неудачных входах, а в Python sorted() и list.sort() — Timsort, гибрид сортировки слиянием и вставками, устойчивый и использующий уже упорядоченные фрагменты без дополнительных затрат. Автором быстрой сортировки был Чарльз Хоар, поэтому в честь него 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^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\) элементов.

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

Сортировка подсчётом

Отсортировать быстрее чем за \(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)\) дополнительной памяти, где \(k\) — мощность множества значений, которые могут встретиться в массиве. Память, выделенная под вспомогательный массив, и есть вся плата за скорость. Чтобы создать этот массив, необходимо знать диапазон возможных значений. В примере потребовался дополнительный массив всего из 12 элементов.

Элементы здесь ни разу не сравниваются друг с другом, поэтому сортировка подсчётом и обходит границу \(O(n \log n)\), доказанную для сортировок сравнением. Работает она за \(O(n + k)\), и выигрыш сохраняется, только пока \(k\) сопоставимо с \(n\). Сортировать таким способом миллион чисел, разбросанных по диапазону до миллиарда, бессмысленно: массив, заведённый под счётчики, окажется в тысячу раз длиннее исходного.

Устойчивость алгоритма

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

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

Резюме

• Рекурсия складывается из базового случая, останавливающего спуск, и рекурсивного, сводящего задачу к меньшей; без базового случая происходит переполнение стека.
• Сортировка слиянием работает за \(O(n \log n)\) даже в худшем случае и устойчива, но требует \(O(n)\) дополнительной памяти под вспомогательный массив.
• Быстрая сортировка в среднем также \(O(n \log n)\) и почти не требует памяти, зато на неудачных разбиениях деградирует до \(O(n^2)\) и порядок равных элементов не сохраняет.
• Опору в быстрой сортировке следует выбирать случайно: любое фиксированное правило можно обойти массивом, подобранным намеренно.
• Сортировка подсчётом не сравнивает элементы вовсе, благодаря чему обходит границу \(O(n \log n)\), но применима лишь на небольшом диапазоне значений и стоит \(O(k)\) памяти.
• Устойчивость является критерием выбора: она необходима всякий раз, когда данные сортируют несколько раз подряд по разным ключам.
• Собственную сортировку в рабочем коде писать незачем, потому что встроенная почти всегда быстрее и лучше отлажена; знать, как она устроена, необходимо, чтобы понимать, чего от неё ожидать.

Хеш-функции

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

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

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

Понятие отображения

В интерфейсе массива, рассмотренном в главе про структуры данных, имеются две основные операции:

• 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, и оба ключа указывают на одну корзину.

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

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

В обоих случаях стоимость операции зависит от числа ключей, делящих одну корзину. Пока хеш-функция распределяет ключи равномерно, а корзин достаточно, цепочки остаются короткими, и поиск, вставка и удаление стоят в среднем \(O(1)\). Если же коллизий много, хеш-таблица вырождается в список пар, с которого начиналось рассмотрение, и поиск снова обходится в \(O(n)\).

Коэффициент заполнения и перехеширование

Условие «корзин достаточно» выражается числом. Отношение количества ключей в таблице к количеству корзин называют коэффициентом заполнения (англ. load factor): пока он мал, цепочки коротки и почти все корзины пусты, а когда он приближается к единице, ключи теснятся и каждая операция сопровождается перебором.

Как только коэффициент превышает порог, выбранный реализацией (в CPython у словаря это две трети, у множества — три пятых), заводится новый массив корзин, в несколько раз больший прежнего, и все ключи раскладываются по нему заново: номер корзины вычисляется по модулю \(M\), а \(M\) изменилось. Эту перестройку называют перехешированием (англ. rehashing).

Стоит она \(O(n)\), но происходит редко и с каждым разом всё реже, поскольку таблица растёт не на одну корзину, а кратно. Та же арифметика рассмотрена в главе «Основные структуры данных» под заголовком «Реаллокация в динамических массивах»: редкие дорогие перестройки, распределённые по множеству дешёвых операций, дают амортизированную \(O(1)\).

Выбор размера хеш-таблицы и вычисление номера корзины

Вычисление номера корзины методом деления

Простейший способ получить номер корзины \(\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\) уменьшает число столкновений.

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

Вычисление номера корзины методом умножения

Другой распространённый способ вычисления номера ячейки — метод умножения. Целое число обозначим на этот раз буквой \(h\), чтобы подчеркнуть, что это хеш ключа. Пусть количество корзин равно \(M\), а также зададим константу \(\alpha \in (0,1)\).

Тогда \(\mathrm{bucket}(h) = \left [ M \cdot \left { h \cdot \alpha \right } \right ]\) , где \(\left [ x \right ]\) обозначает целую часть числа \(x\), а \(\left { x \right }\) его дробную часть.

Алгоритм построения хеш-функции, опирающийся на метод умножения:

• Хеш ключа \(h\) домножается на выбранную константу \(\alpha\).
• От результата берётся дробная часть. Получается значение из диапазона \([0,1)\). Числа для разных ключей окажутся равномерно рассеяны.
• Полученное значение домножается на размер таблицы \(M\). Числа получаются распределёнными в диапазоне \([0, M)\)
• От результата берётся целая часть. С равными вероятностями получаются числа от \(0\) до \((M−1)\) — номера корзин. Равномерно заполняемые корзины дают меньше коллизий.

Дональд Кнут показал, что хеш-функция получается хорошей, если брать в качестве \(\alpha\) число, обратное золотому сечению. $$ \displaystyle \alpha = \phi^{-1} = \left ( \frac{\sqrt 5 -1}{2} \right ) = 0.6180339887... $$

Свойства хеш-функций

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

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

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

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

• Детерминизм. Для одного и того же ключа функция всегда возвращает одинаковое значение. Если внутри используется случайное число, повторный вызов может вернуть новый индекс ячейки, и данные из хеш-таблицы окажутся недоступны. Например, взятие числа по модулю другого числа детерминировано: результат, вычисленный дважды, не изменится.
• Эффективность. Хеш-функция, вызываемая на каждой операции, должна вычисляться быстро. Сложность операции поиска складывается из сложности вычисления хеша и сложности поиска данных по хешу.
• Ограниченность. Результат функции должен принадлежать диапазону, задаваемому размером хеш-таблицы. Поэтому обычно сначала вычисляется хеш-функция, возвращающая произвольное число, а затем результат берётся по модулю \(M\), равного размеру хеш-таблицы. Тогда любой ключ окажется в интервале от \(0\) до \(M-1\), и обращения к индексу, не отвечающему ни одной из корзин, не произойдёт.
• Равномерность. Данные должны быть распределены по хеш-таблице равномерно, то есть каждое выходное значение равновероятно: при запуске функции для каждого элемента большого списка разных объектов получится примерно равное число ответов на каждое значение от \(0\) до \(M-1\). В противном случае в некоторые ячейки запись будет производиться чаще, чем в остальные, и обращение к таблице замедлится. Пример неравномерной функции — среднесуточная температура по городу и дате: большую часть времени она держится на одном уровне, а аномальные морозы или жара случаются редко.

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

• Лавинность. При незначительном изменении входных данных выходное значение должно меняться значительно. При хешировании паролей функция, лишённая лавинности, взламывается проще. Если злоумышленнику известно, что \(h(aa) = 22\), а \(h(bb) = 33\), то он может предположить такой \(password\), что \(h(password) = 44\). Перебрав небольшое число вариантов, он подберёт пароль по его хешу.
• Необратимость. Невозможно восстановить ключ по значению функции. Например, при регистрации на сайте к паролю пользователя применяется хеш-функция, и полученный хеш записывается в базу данных. Каждый раз, когда пароль вводится заново, к нему применяется та же функция, и новый хеш совпадёт с записью в базе, если введён исходный пароль. Даже получив доступ к базе, злоумышленник не должен иметь возможности восстановить пароль по украденным хешам.

Построение хеш-функций для строк

Хеш-функции для строк вычисляются «полиномиальным хешированием» (от слова «полином», то есть многочлен). Хеш строки \(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\) не столь важен, поскольку в сумму войдут значения \(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 подмешивает в хеш случайную соль, выбираемую при запуске интерпретатора. Это сделано для защиты от атак, при которых сервер получает ключи, подобранные под одну корзину, и на работу словаря внутри одного процесса не влияет: там хеш, вычисленный дважды, совпадает сам с собой.

Поисковый индекс

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

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

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

Отображение, которое ставит каждому объекту в соответствие его расположение, называют «поисковым индексом».

Хеш-таблица должна находить позиции любой подстроки, а значит, в неё необходимо заранее добавить все подстроки текста. Если подстроки в таблице нет, нет её и в тексте.

Позиция при этом получается сразу, однако такой способ расточителен по памяти. Подстрок в тексте столько, сколько способов выбрать две границы: \(N\cdot(N+1)/2\), где \(N\) — длина текста. Следовательно, в хеш-таблицу требуется добавить \(O(N^2)\) пар (key, value). Поскольку ключами служат сами подстроки, каждая пара займёт в среднем \(O(N)\) памяти, а всего — \(O(N^3)\).

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

На практике индексируют не все подстроки, а слова, разделённые пробелами. Текст разбивается на слова, и в хеш-таблицу помещаются пары из слова и списка его позиций. Таких пар \(O(N)\), памяти требуется линейное количество, а поиск по целому слову остаётся мгновенным. Так устроены поисковые системы и полнотекстовый поиск в базах данных, только вместо списка позиций там хранятся более сложные структуры.

Резюме

• Хеш-таблица превращает поиск по ключу в вычисление: хеш-функция вычисляет по ключу число, остаток от деления этого числа на количество корзин даёт номер ячейки, а далее работает обычный массив.
• Коллизии неизбежны у любой хеш-функции, и разрешаются они либо методом цепочек, когда в корзине хранится список пар, либо открытой адресацией, когда пара помещается в ближайшую свободную ячейку.
• Ожидаемая \(O(1)\) обеспечивается двумя условиями: хеш-функция распределяет ключи равномерно, а корзин достаточно. Второе обеспечивается перехешированием, стоящим \(O(n)\) на редких перестройках и потому не ухудшающим среднюю стоимость.
• От хеш-функции требуются детерминизм, эффективность, ограниченность и равномерность, а от криптографической — дополнительно лавинность и необратимость.
• Число корзин выбирается простым, чтобы закономерности, скрытые во входных ключах, не приводили раз за разом в одну ячейку.
• Строки хешируются полиномиально, по модулю большого числа \(R\), выбранного взаимно простым с основанием \(q\) и числом корзин.
• Поисковый индекс представляет собой ту же хеш-таблицу, где ключом служит слово, а значением — список его позиций; на нём основан и полнотекстовый поиск в базах данных.

Деревья

В массиве, связном списке, стеке и очереди элементы выстроены друг за другом. Однако файловая система на диске, структура HDF5-файла с результатами измерений, иерархия объёмов детектора в Geant4, дерево вызовов, собранное профилировщиком, устроены как иерархии. Для их описания существует отдельная структура данных — дерево.

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

Понятие дерева

Деревом называют набор узлов (вершин), соединённых рёбрами, в котором выполнены три условия:

• есть один выделенный узел, корень (англ. 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, вмещающую самый широкий уровень.

Двоичное дерево поиска

Двоичным деревом поиска (англ. 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 \), задающей цену любой операции. Если вставлять ключи в случайном порядке, \( h \approx \log_2 n \). Но если вставить ключи 1, 2, 3, ..., n по порядку, каждый новый узел уйдёт направо, и дерево выродится в связный список высоты \( n \). Все операции станут линейными.

Дерево называется сбалансированным, если у каждого узла высоты левого и правого поддеревьев отличаются не больше чем на единицу. У такого дерева \( h = O(\log n) \), а значит, все операции работают за \( O(\log n) \).

Сохранять сбалансированность при любых вставках и удалениях позволяют самобалансирующиеся деревья (АВЛ-дерево, красно-чёрное дерево), выполняющие после каждой операции небольшие локальные перестройки, называемые поворотами. Именно они стоят за std::map в C++ и TreeMap в Java, упомянутыми в главе про хеш-таблицы. В стандартной библиотеке Python дерева поиска нет, поскольку обычно достаточно dict, set и модуля bisect для отсортированного списка.

Куча

Куча (англ. 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 над обычным списком, передаваемым в функции модуля:

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)

Если требуется max-heap, в куче хранят элементы с обратным знаком. Этот приём применяется в следующей главе, в алгоритме, строящем остовное дерево.

Пирамидальная сортировка

Куча даёт ещё один способ сортировать за \( 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) \). В SciPy оно уже реализовано:

import numpy as np
from scipy.spatial import KDTree

points = np.random.rand(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. \]

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

\[ 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 с примерно 16 значащими цифрами, а промежуточный \( 40! \approx 8{,}16 \cdot 10^{47} \) точно в нём не представим. До \( n = 30 \) ответ всё же получается верным: ошибки в числителе и знаменателе компенсируют друг друга при делении. А \( C_{31} \) наивная формула уже занижает на единицу. Целочисленный вариант ничем не сложнее.

Сложность. Формула с биномиальным коэффициентом требует \( 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.

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

Графы

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

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

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

Определения

Граф \( 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 v) \) вместо \( 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 естественно записывается через рекурсию и применяется для поиска циклов, топологической сортировки, компонент связности и анализа структуры графа.

Кратчайшие пути

В невзвешенном графе кратчайший путь находит 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) \). Веса обязаны быть неотрицательными: на отрицательных рёбрах жадная стратегия перестаёт работать, и требуется алгоритм Беллмана — Форда.

Топологическая сортировка

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

Простейший способ — DFS: вершина добавляется в результат после всех потомков, а список в конце разворачивается.

def topological_sort(graph, vertices):
    """Топологическая сортировка ориентированного ациклического графа."""
    visited = set()
    order = []

    def visit(vertex):
        visited.add(vertex)
        for neighbour in graph[vertex]:
            if neighbour not in visited:
                visit(neighbour)
        order.append(vertex)      # добавляем на выходе из вершины

    for vertex in vertices:
        if vertex not in visited:
            visit(vertex)
    return order[::-1]            # разворачиваем

Минимальное остовное дерево

Остовным деревом (англ. spanning tree) связного графа называется подмножество рёбер, связывающее все вершины и не содержащее циклов, то есть дерево, натянутое на все \( n \) вершин и собранное из \( n-1 \) ребра. Минимальным остовным деревом (MST) называется то, у которого суммарный вес рёбер наименьший. Классическая постановка требует соединить все дома оптоволокном, затратив минимум кабеля.

Два классических алгоритма, оба жадные:

• Алгоритм Прима наращивает дерево из одной вершины: на каждом шаге добавляется самое лёгкое ребро, ведущее из уже построенной части наружу. Удобно реализуется через кучу, сложность \( O(m \log n) \). По существу это алгоритм Дейкстры, только вместо расстояния от старта минимизируется вес одного ребра.
• Алгоритм Краскала исходит от рёбер: сортирует их все по весу и добавляет по очереди те, которые не образуют цикл. Проверка на цикл выполняется структурой «система непересекающихся множеств» (DSU). Сложность \( O(m \log m) \).

Если в алгоритме Прима заменить «минимальное ребро» на «максимальное», получится максимальное остовное дерево; эта задача рассматривается в конце главы.

Графы в физических задачах

• Электрические цепи. Схема представляет собой граф из узлов и ветвей. Законы Кирхгофа записываются через матрицу инцидентности, а число независимых контурных уравнений равно \( m - n + 1 \), то есть количеству рёбер, не вошедших в остовное дерево.
• Модель Изинга и перколяция. Спины на решётке служат вершинами, а взаимодействия соседей рёбрами. Алгоритмы кластерного обновления (Свендсена — Ванга, Вольфа) сводятся к поиску компонент связности, а перколяция — вопрос о существовании компоненты, соединяющей края решётки.
• Молекулы и структуры. Атомы и химические связи образуют граф, а поиск колец в молекуле сводится к поиску циклов. На этом же представлении работают графовые нейронные сети, предсказывающие свойства веществ.
• Марковские цепи и графы состояний. Состояния системы становятся вершинами, а переходы, снабжённые вероятностями, взвешенными рёбрами орграфа.
• Трассировка и планирование. Разводка кабелей на установке, маршрут манипулятора, план эксперимента сводятся к задачам о кратчайшем пути или об остовном дереве.

Для практических расчётов реализовывать алгоритмы вручную не обязательно: готовые собраны в библиотеке 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 реализует лишь 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) \).
• Посещённые вершины необходимо помечать: в отличие от дерева, у графа есть циклы, и без пометок обход не завершится.
• Компоненты связности, топологическая сортировка и остовные деревья — три классических применения обходов, к которым сводится множество практических задач.

Жизненный цикл программного обеспечения

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

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

Основные стадии жизненного цикла

Жизненный цикл ПО состоит из семи стадий:

1. Анализ. Выясняется, что именно требуется построить.
2. Проектирование. Определяется, как это будет устроено.
3. Разработка. Пишется код.
4. Тестирование. Проверяется, что получилось именно задуманное.
5. Релиз. Продукт доводится до пользователя.
6. Поддержка. Сопровождается работающая система.
7. Завершение жизненного цикла. Продукт снимается с поддержки.

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

Анализ и планирование

На этапе анализа собираются требования к будущему продукту и сводятся в документ Software Requirements Specification (SRS).

IEEE 830-1998

Структуру такого документа задавал стандарт IEEE 830-1998, отменённый и заменённый на ISO/IEC/IEEE 29148. Предложенная им структура сохранилась:

1. Назначение
2. Общее описание
3. Конкретные требования
4. Интерфейсы
5. Ограничения
6. Атрибуты качества

Ключевые задачи этапа анализа

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

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

Проектирование

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

Design-review

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

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

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

Security-review

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

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

MVP (Minimum Viable Product)

Минимально жизнеспособный продукт — самая маленькая версия, которой уже можно пользоваться. Смысл заключается в том, чтобы как можно раньше выяснить, тот ли продукт создаётся. Для лабораторного инструмента MVP обычно выглядит так: одна команда, один формат входных файлов, никаких настроек. Она вычисляет задуманное, и её можно передать коллеге.

Разработка

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

Системы контроля версий

Система контроля версий (VCS) хранит историю изменений с указанием того, кто, что и когда правил, и позволяет вернуться к любому прошлому состоянию. Решать эту задачу начали в 1960-х с IEBUPDTE, затем были SCCS в 1970-х, RCS и CVS в 1980-х, а SVN и Git появились в 2000-х.

Поколения различаются тем, где хранится история. Централизованные системы (CVS, SVN) хранят её на сервере, и без связи с ним нельзя ни просмотреть историю, ни сделать коммит. Распределённые системы (Git, Mercurial) дают каждому участнику полную копию репозитория со всей историей, поэтому работать можно без сети, а синхронизироваться впоследствии.

Стандартом де-факто является Git, написанный Линусом Торвальдсом в 2005 году для разработки ядра Linux, когда команда лишилась доступа к использовавшейся до того проприетарной системе. Главной его особенностью является дешёвое ветвление. Создание ветки ничего не копирует, заводится лишь указатель на коммит, поэтому ветвиться и сливать можно постоянно. Устройству Git и повседневным командам посвящена отдельная глава.

Вокруг ветвления сложились схемы работы. Git Flow поддерживает долгоживущие ветки релизов, более простой GitHub Flow сливает всё в основную ветку через pull request'ы, принятые ревьюером; между ними находится GitLab Flow. Выбор определяется тем, как часто выходят релизы. Научной группе почти всегда достаточно самой простой схемы.

Ревью кода

Pull request (или merge request) — предложение влить в общую ветку сделанные разработчиком изменения. Он решает три задачи: делает правку видимой для всей команды, предоставляет место для обсуждения до того, как код попал в основную ветку, и служит точкой, к которой привязываются автоматические проверки.

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

Монорепозиторий

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

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

Тестирование

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

Проверки выстроены пирамидой, от самых дешёвых и частых к самым дорогим и редким.

Статический анализ

Самая дешёвая проверка не запускает программу. Анализатор читает исходный код и ищет в нём ошибки, отклонения от стиля и подозрительные места. Так обнаруживаются неиспользуемые переменные, опечатки в именах, потенциальные None, измеряются цикломатическая сложность и доля дублированных строк. Покрытие тестами также попадает в отчёты о качестве, но получают его иначе, выполняя тесты под coverage.py (pytest --cov): узнать, какие строки выполнялись, не выполнив их, нельзя.

Анализатор, встроенный в редактор и в CI, в дальнейшем работает самостоятельно.

«Самое важное, что я сделал как программист за последние годы, — начал агрессивно применять статический анализ кода» — Джон Кармак

Модульные тесты

Модульный тест (unit test) проверяет одну функцию или класс, отделённые от всего остального. Их пишут много, они выполняются за секунды и запускаются на каждое изменение.

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

Интеграционные и функциональные тесты

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

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

Нагрузочное тестирование

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

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

Релиз

Главной заботой при выкатке является возможность быстро откатиться в случае поломки.

Стратегии развёртывания

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

• Blue-green. Поддерживаются две одинаковые среды. Новая версия выкатывается на неактивную, проверяется, и трафик переключается одним действием. Откат — переключение обратно.
• Canary. Новая версия сначала показывается небольшой доле пользователей. Если метрики не ухудшились, доля увеличивается.
• Rolling update. Экземпляры приложения заменяются по одному, сервис всё это время продолжает отвечать.
• A/B-тестирование. Две версии работают одновременно на разных группах, и выбор между ними делается по измеренному результату.

Feature-флаги

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

Момент выпуска

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

CI/CD

Перечисленные проверки выполняет конвейер CI/CD. За тремя похожими аббревиатурами скрываются три степени автоматизации.

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

Непрерывная поставка (CD, Continuous Delivery) добавляет автоматическую сборку дистрибутивов и развёртывание на тестовые среды. Система в любой момент готова к выкатке и ожидает решения человека.

Непрерывное развёртывание (CD, Continuous Deployment): прошедшие все проверки изменения попадают в продакшен без участия человека. Это требует уверенности в тестах.

Научной группе обычно достаточно первого уровня. CI, выполняющий на каждый push тесты и линтер, окупается на второй месяц.

Устройство реального конвейера

Ниже приведён конвейер научной библиотеки REDPIC, кода для расчёта динамики пучка, которому отведена отдельная глава. Написанный для GitHub Actions, он умещается в одну страницу.

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

steps:
  - name: Checkout sources
    uses: actions/checkout@v4

  - name: Set up Python
    uses: actions/setup-python@v5
    with:
      python-version: ${{ matrix.python-version }}

Строка ${{ matrix.python-version }} задаёт матричную сборку. Один и тот же набор шагов выполняется на нескольких версиях Python, и если библиотека перестала работать на 3.12, но работает на 3.10, это выясняется сразу. Для библиотеки, передаваемой незнакомым людям, такая проверка обязательна: разработчик не управляет тем, какой Python установлен у пользователя.

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

  - 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. Тесты также являются кодом, и приходят в негодность они не реже основного.

Вторая работа выполняет тесты:

  - name: Run functional test
    run: python -m pytest tests/functional/src

Третья работа выпускает релиз. Она запускается только на поставленный автором тег версии. Собранный пакет отправляется в PyPI и становится доступен по pip install redpic:

  - 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@v2
    env:
      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
    with:
      files: dist/${{ env.name }}

Пароли и токены в конвейере никогда не записываются открытым текстом: они помещаются в хранилище секретов репозитория и подставляются по имени (secrets.GITHUB_TOKEN). Секрет, закоммиченный в репозиторий, считается скомпрометированным навсегда: история git хранит всё, и удаление следующим коммитом ничего не исправляет.

Каждое чужое действие — код, выполняемый в конвейере разработчика с доступом к его секретам, поэтому у него должен быть указан тег или хеш коммита. Запись вида @master означает «взять из чужой ветки то, что там находится сегодня», и подменить это может любой, имеющий доступ к тому репозиторию. В примере выше @release/v1 — также ветка, однако PyPA поддерживает её под стабильные выпуски и сама рекомендует такую запись; для строгости лучше указывать хеш коммита.

Четвёртая работа собирает документацию из исходников, публикует её на GitHub Pages и прикладывает PDF-версию к релизу:

  - name: Upload Release Asset (pdf) to GitHub
    uses: softprops/action-gh-release@v2
    with:
      files: manual/main.pdf

  - name: Push documentation changes
    uses: peaceiris/actions-gh-pages@v4
    with:
      github_token: ${{ secrets.GITHUB_TOKEN }}
      publish_dir: gh-pages

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

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

Задание. Выступить в роли рецензента: «Ревью чужого кода».

Сопровождение

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

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

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

Завершение жизненного цикла

Рано или поздно программу перестают поддерживать. Об этом следует объявить заранее, дать пользователям время и путь перехода на замену, а данные выгрузить в формате, переживающем сам сервис.

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

Резюме

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

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

Требования к коду на Python

Требования к коду на Python, действующие в этой книге, рекомендуется соблюдать и в собственных проектах:

• Строгое соответствие 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), иначе форматтер будет конфликтовать с линтером на каждом коммите.

Задание. Применить этот список к чужому коду и оставить замечания: «Ревью чужого кода».

От скрипта к приложению

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

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

• через полгода в скрипте, разросшемся до 800 строк, появляются калибровка, три формата входных файлов и ветка if experiment == "march":;
• рядом лежат analysis_new.py, analysis_final.py и analysis_final_v2_REAL.py, и никто не помнит, чем они отличаются;
• пути к данным (/home/vasya/data/2026-03-12/) и параметры установки зашиты в код, и перед каждым запуском их правят в исходнике;
• на другой машине скрипт не запускается, и начинается выяснение версий numpy;
• приходит новый студент, и автору скрипта приходится полчаса объяснять, какие строки закомментировать, чтобы «просто посчитать спектр».

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

Разница между скриптом и приложением заключается не в количестве строк, а в свойствах:

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

Глава про жизненный цикл ПО рассматривала разработку сверху. В настоящей главе весь путь проходится на одном примере: скрипт обработки осциллограмм превращается в пакет beamtool для всей группы.

В примерах встретится NumPy: loadtxt читает таблицу чисел из файла, argmax возвращает индекс максимума, trapezoid вычисляет интеграл методом трапеций. Устройство массивов разбирается в главе «NumPy и pandas»; здесь важна обвязка вокруг библиотеки.

Структура проекта

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

Типовая структура:

beamtool/                  # корень git-репозитория
├── pyproject.toml         # метаданные проекта и зависимости
├── README.md              # что это, как поставить, как запустить
├── .gitignore
├── configs/
│   └── default.toml       # параметры обработки по умолчанию
├── src/
│   └── beamtool/          # сам пакет
│       ├── __init__.py
│       ├── io.py          # чтение и запись данных
│       ├── physics.py     # формулы и численные методы
│       ├── plotting.py    # вся работа с matplotlib
│       └── cli.py         # интерфейс командной строки
└── tests/
    ├── test_io.py
    └── test_physics.py

Это src-layout: пакет расположен в каталоге src/. Существует и плоский вариант (flat layout), при котором beamtool/ лежит в корне репозитория; для небольших проектов допустим и он. Преимущество src-layout заключается в том, что пакет нельзя случайно импортировать из рабочего каталога, минуя установку, и тесты проверяют именно то, что получит пользователь.

Сырые данные с установки в репозиторий не помещают: git плохо переносит гигабайты бинарных файлов, а история изменений для них бессмысленна. Данные хранятся на сервере или дисках группы, в репозитории остаются путь к ним в конфигурации и небольшие файлы-образцы для тестов (tests/data/). Каталоги data/, .venv/, __pycache__/ и файлы *.log необходимо добавить в .gitignore до первого коммита, иначе в историю попадут два гигабайта данных.

Виртуальные окружения и зависимости

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

cd beamtool
python -m venv .venv
source .venv/bin/activate    # в Windows: .venv\Scripts\activate
pip install numpy matplotlib

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

Классический способ — файл requirements.txt, список, передаваемый команде pip install -r requirements.txt.

numpy==2.1.3
matplotlib==3.9.2

Современный способ — секция dependencies в pyproject.toml, едином файле с метаданными проекта (он рассматривается в разделе про упаковку). Для нового проекта предпочтительнее pyproject.toml; requirements.txt остаётся как точный слепок собранного окружения.

Режимов закрепления версий два. В библиотеке, устанавливаемой другими, версии ограничивают мягко (numpy>=2.0), чтобы не конфликтовать с чужими зависимостями. В приложении для обработки данных важнее воспроизводимость: pip freeze > requirements.txt фиксирует всё окружение до последней цифры, что позволяет через год пересоздать его и повторить расчёт из статьи. Обновление той же scipy иногда изменяет численные результаты в последних знаках, а для науки это является основанием зафиксировать версии жёстко.

Вместо связки venv + pip можно использовать менеджер проектов, poetry или uv. Они выполняют те же действия: окружение, зависимости и lock-файл с точными версиями, но одной командой и с автоматическим разрешением конфликтов; uv, написанный на Rust, к тому же работает на порядок быстрее pip. Начинать следует с venv и pip, чтобы понимать механику, а переход на менеджеры целесообразен тогда, когда становится ясно, какую рутину они устраняют.

Точки входа

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

if __name__ == "__main__":
    main()

Переменная __name__ равна "__main__" только у файла, запущенного как программа, а не импортированного. Это уже входило в наши требования к коду; следующий шаг — интерфейс командной строки, чтобы параметры передавались аргументами, а не правкой исходника. В стандартной библиотеке для этого предусмотрен модуль argparse:

"""Интерфейс командной строки beamtool."""

import argparse
from pathlib import Path

import numpy as np


def parse_args() -> argparse.Namespace:
    """Разбирает аргументы командной строки."""
    parser = argparse.ArgumentParser(
        prog="beamtool",
        description="Обработка осциллограмм: базовая линия, пик, заряд.",
    )
    parser.add_argument(
        "--input", type=Path, required=True,
        help="входной CSV-файл с колонками time, voltage",
    )
    parser.add_argument(
        "--output", type=Path, required=True,
        help="файл для записи результатов",
    )
    parser.add_argument(
        "--plot", action="store_true",
        help="показать график после обработки",
    )
    parser.add_argument(
        "--baseline-points", type=int, default=100,
        help="сколько первых точек считать базовой линией",
    )
    return parser.parse_args()


def main() -> None:
    """Точка входа приложения."""
    args = parse_args()
    time, voltage = np.loadtxt(
        args.input, delimiter=",", skiprows=1, unpack=True)

    # Базовая линия — среднее по первым точкам до прихода сигнала.
    baseline = voltage[:args.baseline_points].mean()
    signal = voltage - baseline
    peak_index = int(np.argmax(signal))
    area = float(np.trapezoid(signal, time))

    np.savetxt(
        args.output,
        [[time[peak_index], signal[peak_index], area]],
        delimiter=",",
        header="peak_time,peak_voltage,area",
    )

    if args.plot:
        # Ленивый импорт: без --plot matplotlib даже не загружается,
        # и скрипт работает на сервере без дисплея.
        from beamtool.plotting import show_signal
        show_signal(time, signal, peak_index)


if __name__ == "__main__":
    main()

Запуск: python -m beamtool.cli --input shot_042.csv --output results.csv --plot. Команда заработает после установки пакета в окружение (pip install -e ., см. раздел про упаковку); до установки при src-layout запуск осуществляется командой PYTHONPATH=src python -m beamtool.cli …. Дополнительно предоставляется --help: argparse самостоятельно генерирует справку, проверяет обязательные аргументы и приводит типы к объявленным. Пользователю не требуется открывать код, а значит, он не сможет случайно его повредить.

Для интерфейсов с подкомандами (как git commit, git push) существуют сторонние библиотеки click и typer, решающие ту же задачу декораторами и аннотациями типов. Однако argparse из стандартной библиотеки достаточно на долгое время, и он всегда доступен.

Конфигурация

Магические числа и пути в коде являются основным источником хаоса в лабораторных скриптах. Порог дискриминатора, частота дискретизации АЦП, путь к данным меняются от запуска к запуску и, будучи зашитыми в исходник, требуют правки кода. История в git превращается в набор записей «поменял порог обратно», а воспроизводимость теряется, потому что никто не помнит, с какими параметрами получен график из статьи.

Код отвечает на вопрос «как считать», конфигурация — «что и с какими параметрами». Вынесенные параметры помещают в конфигурационный файл; удобным форматом является TOML, читаемый стандартной библиотекой (Python 3.11+).

# configs/default.toml

[detector]
sampling_rate_hz = 2.5e9   # частота дискретизации АЦП
impedance_ohm = 50.0

[analysis]
baseline_points = 100      # точек на оценку базовой линии
peak_threshold_v = 0.05    # порог отбора событий

import tomllib

with open("configs/default.toml", "rb") as f:
    config = tomllib.load(f)

threshold = config["analysis"]["peak_threshold_v"]

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

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

import os

data_dir = os.environ.get("BEAMTOOL_DATA_DIR", "/data/beam")

Пароли и токены, например доступ к базе данных группы (о них в главе про базы данных), не попадают ни в код, ни в git. Допустимы только переменные окружения или локальный файл .env, добавленный в .gitignore. Общепринятый приоритет источников: значения по умолчанию → конфигурационный файл → переменные окружения → аргументы командной строки; каждый следующий уровень перекрывает предыдущий.

Логирование вместо print

print пригоден для кратковременной отладки. Далее возникают проблемы: отладочный вывод, разбросанный по коду, нельзя отключить, не удаляя его; у сообщений нет ни времени, ни уровня важности; всё уходит в консоль и исчезает вместе с закрытым окном. Когда же ночная обработка останавливается с ошибкой на 3742-м файле из 5000, необходим журнал, сохранивший, что происходило, с какими файлами и когда.

Всё это обеспечивает logging из стандартной библиотеки. У сообщений пять уровней (DEBUG, INFO, WARNING, ERROR, CRITICAL) и глобальный порог, определяющий, что показывать. Настройка, пишущая одновременно в консоль и в файл:

import logging

logger = logging.getLogger(__name__)


def setup_logging(logfile: str = "beamtool.log") -> None:
    """Включает вывод логов в консоль и в файл одновременно."""
    logging.basicConfig(
        level=logging.INFO,
        format="%(asctime)s %(levelname)-8s %(name)s: %(message)s",
        handlers=[
            logging.StreamHandler(),
            logging.FileHandler(logfile, encoding="utf-8"),
        ],
    )

Использование в коде:

logger.info("Загружен файл %s: %d точек", path, n_points)
logger.warning("Пик ниже порога %.3f В, файл пропущен", threshold)
logger.error("Не удалось разобрать файл %s", path, exc_info=True)

getLogger(__name__) в каждом модуле создаёт именованный логгер, и в журнале видно, какой модуль пишет. Флаг --verbose в CLI может понижать порог до DEBUG, не затрагивая код; отладочные сообщения пишутся всегда, а показываются по требованию. exc_info=True добавляет к сообщению полный traceback, так что наутро в журнале обнаружится не только «файл пропущен», но и причина.

Обработка ошибок

Главным принципом научного кода является fail fast: при обнаружении некорректных данных программа должна останавливаться сразу и явно. Тихий NaN проходит через все стадии обработки и превращается в правдоподобный, но неверный график. Остановившуюся программу исправляют; красивую кривую с ошибкой отправляют в статью.

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

import numpy as np


class BeamtoolError(Exception):
    """Базовый класс ошибок beamtool."""


class InvalidSignalError(BeamtoolError):
    """Сигнал не пригоден для обработки."""


def find_peak(signal: np.ndarray) -> int:
    """Возвращает индекс максимума сигнала."""
    if signal.size == 0:
        raise InvalidSignalError("пустой сигнал")
    if not np.all(np.isfinite(signal)):
        raise InvalidSignalError("в сигнале есть NaN или inf")
    return int(np.argmax(signal))

Собственные классы отделяют ожидаемые ошибки от дефектов кода. На верхнем уровне, в main(), перехватывается except BeamtoolError, и некорректный файл в пачке из тысячи оказывается штатной ситуацией: запись в журнал и переход к следующему. KeyError или TypeError, напротив, означают дефект в самом коде; такое исключение должно пройти наружу с полным traceback, чтобы его исправили.

Худшее, что можно сделать с исключением, — подавить его:

# Так делать нельзя: ошибка исчезает бесследно,
# а в результатах молча появляется дыра.
try:
    result = process(path)
except Exception:
    pass

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

Тесты

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

Стандартом де-факто является pytest: тесты лежат в tests/test_*.py, называются test_* и состоят из обычных assert. Рассмотрим функцию из beamtool:

# src/beamtool/physics.py

ELECTRON_REST_ENERGY_MEV = 0.511


def lorentz_gamma(kinetic_energy_mev: float) -> float:
    """Возвращает лоренц-фактор по кинетической энергии электрона."""
    if kinetic_energy_mev < 0:
        raise ValueError("кинетическая энергия отрицательна")
    return 1.0 + kinetic_energy_mev / ELECTRON_REST_ENERGY_MEV

И тесты к ней:

# tests/test_physics.py

import pytest

from beamtool.physics import lorentz_gamma


def test_gamma_at_rest():
    # Покоящийся электрон: гамма-фактор равен единице.
    assert lorentz_gamma(0.0) == pytest.approx(1.0)


def test_gamma_one_mev():
    assert lorentz_gamma(1.0) == pytest.approx(2.9569, abs=1e-4)


def test_negative_energy_rejected():
    with pytest.raises(ValueError):
        lorentz_gamma(-1.0)

Команда pytest в корне проекта самостоятельно находит и выполняет все тесты. Сравнивать float через == нельзя из-за ошибок округления в последних знаках; pytest.approx сравнивает с заданным допуском, абсолютным (abs=) или относительным (rel=).

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

Типизация

Аннотации типов присутствовали во всех примерах выше:

def rebin(spectrum: np.ndarray, factor: int = 2) -> np.ndarray:
    """Огрубляет спектр, суммируя соседние каналы."""
    n_bins = spectrum.size // factor * factor
    return spectrum[:n_bins].reshape(-1, factor).sum(axis=1)

Во время выполнения Python их не проверяет: аннотации представляют собой документацию, читаемую машиной. Редактор подсказывает атрибуты и обнаруживает опечатки, а статический анализатор mypy командой mypy src/ находит несоответствия до запуска: в одном месте передан str вместо Path, в другом функция может вернуть None, а вызывающий код об этом не знает. Аннотировать имеет смысл хотя бы функции публичного интерфейса пакета, а mypy добавить в CI рядом с линтерами.

Документация

Docstring у каждой публичной функции сообщает, что она делает, что принимает, что возвращает и в каких единицах (перепутанные мэВ и МэВ не обнаружит ни один тайпчекер). README в корне репозитория отвечает на три вопроса: что это за проект, как его установить, как запустить, и содержит один работающий пример команды; это первое, что увидит коллега, и часто единственное, что он прочтёт. Когда проект вырастает, из docstring'ов и markdown-файлов собирают сайт документации при помощи mkdocs или sphinx; документация хранится в том же репозитории и обновляется вместе с кодом, а не в отдельном текстовом документе на сетевом диске.

Упаковка и распространение

Центральным файлом современного Python-проекта является pyproject.toml.

[project]
name = "beamtool"
version = "0.1.0"
description = "Обработка осциллограмм с датчиков пучка"
requires-python = ">=3.11"
dependencies = [
    "numpy>=2.0",
    "matplotlib>=3.9",
]

[project.scripts]
beamtool = "beamtool.cli:main"

[build-system]
requires = ["setuptools>=68"]
build-backend = "setuptools.build_meta"

Установка в окружение в режиме разработки:

pip install -e .

Флаг -e (editable) устанавливает пакет ссылкой на рабочий каталог, и правки видны сразу, без переустановки. После установки работают импорты from beamtool.physics import ... из любого места, в том числе из тестов. Секция [project.scripts] создаёт в окружении консольную команду, и функция main() из cli.py вызывается как beamtool --input shot_042.csv --output results.csv.

Коллегам из группы достаточно git-репозитория: pip install git+https://github.com/mygroup/beamtool устанавливает пакет со всеми объявленными зависимостями. Команда python -m build собирает wheel-файл в dist/, который можно приложить к релизу на GitHub или передать на машину без интернета. Публикация на PyPI через twine upload (или uv publish) требуется, когда инструментом предполагают пользоваться незнакомые автору люди; для внутренних инструментов группы она не обязательна.

Рост приложения в систему

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

Такую программу нельзя писать «плоско». Рассмотрим, как устроена библиотека SCAUT, оркеструющая эксперименты на линейном ускорителе инжектора ЦКП «СКИФ». Она согласованно управляет всеми компонентами установки, от магнитов до детекторов.

Ключевой идеей является разделение на слои, где каждый слой знает только о соседнем:

Интерфейс эксперимента   что именно сканируем и в каких пределах
        │
Управление сканированием планировщик точек, обработчики событий, обработка аварий
        │
Абстракция оборудования  «мотор» и «датчик» — независимо от того, что за железо
        │
Коммуникация             EPICS, Tango, OPC UA — или расчётная модель вместо железа
        │
Данные                   сериализация, метаданные эксперимента, хранилище
        │
Анализ                   визуализация, статистика, постобработка

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

Ниже расположен слой коммуникации, отделяющий протокол от смысла. Ускорительными комплексами управляют разные системы, EPICS, Tango, OPC UA, и код эксперимента не должен знать, какая из них находится внизу. На место реального оборудования можно подставить расчётную модель. Тот же сценарий эксперимента, не изменённый ни в одной строке, прогоняется сначала на модели пучка, а потом на установке. Ошибка в логике сканирования обнаруживается на модели, где она ничего не стоит, а не в смену, где она стоит пучкового времени всей группы.

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

Процедура сканирования всегда проходит одни и те же шесть этапов:

1. Инициализация. Проверить, что необходимое оборудование на связи, выставить начальные параметры.
2. Планирование. Построить последовательность точек в пространстве параметров.
3. Выполнение. На каждом шаге выставить параметры и снять данные.
4. Обработка событий. Вызвать пользовательские функции анализа.
5. Сериализация. Сохранить результаты и метаданные.
6. Завершение. Освободить ресурсы, сформировать отчёт.

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

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

Чек-лист: скрипт стал приложением

• Код разложен по модулям со смыслом: ввод-вывод, физика, графика, CLI.
• Проект устанавливается на чистую машину командами git clone и pip install -e ..
• Зависимости с версиями записаны в pyproject.toml, точный слепок собранного окружения можно получить и восстановить.
• Запуск не требует открывать исходники, все параметры передаются через аргументы CLI и конфигурационный файл.
• Пути, калибровки и пороги хранятся в конфигурации, а не в коде; секретов в репозитории нет.
• Вместо print используется logging, и после ночного прогона остаётся журнал, размеченный временем и уровнями.
• Некорректные данные вызывают внятную ошибку сразу, а не тихий NaN, всплывающий в результатах.
• Ключевые формулы покрыты тестами; pytest проходит перед каждым коммитом.
• Публичные функции аннотированы типами и снабжены docstring; mypy не выдаёт замечаний.
• README отвечает на вопросы «что это», «как поставить», «как запустить».
• Файл analysis_final_v2_REAL.py удалён, поскольку версии хранятся в git, а не в именах файлов.

Нет необходимости выполнять всё в первый же вечер. Структура, окружение и git необходимы сразу, они почти ничего не стоят. Конфигурация, логирование и CLI появляются у скрипта, запускаемого чаще раза в неделю. Тесты приходят, как только результатам начинают доверять другие люди. Превращение скрипта в приложение является не событием, а привычкой: вынести константу в конфигурацию, превратить обнаруженный дефект в тест. Сети и хранилище результатов рассматриваются в следующих главах, а развёртывание собственного сервиса — в главе про асинхронность.

Задание. Довести чужой недописанный проект до состояния, в котором его можно развернуть: «Деплой стартапа „Котики в мир“».

Основы компьютерных сетей и веб-технологий

Разбираться в сетях физику приходится потому, что почти любые данные, необходимые для работы, сегодня получаются через сеть. Установка отдаёт телеметрию по TCP, каталог наблюдений находится за HTTP-интерфейсом, расчёт запускается на кластере по SSH, а результаты отправляются на сервер группы. Когда что-либо из этого перестаёт работать, место разрыва быстро находит тот, кто представляет путь от программы до провода.

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

Сетевые модели: OSI и TCP/IP

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

Благодаря такому разделению Wi-Fi был изобретён без переписывания браузеров и протокола IP.

Классическая модель OSI, созданная как эталонная, насчитывает семь уровней:

На практике же применяется более компактная модель TCP/IP из четырёх уровней. Физический и канальный в ней объединены в «уровень сетевого доступа», а три верхних уровня OSI слиты в один прикладной. Так устроен интернет; далее изложение ведётся по этой модели снизу вверх.

Уровень сетевого доступа

Самый нижний уровень отвечает на вопрос «как физически доставить биты соседнему узлу».

Физический уровень

Средой передачи здесь являются витая пара и коаксиальный кабель, оптоволокно (одномодовое для дальних линий, многомодовое для коротких), радио в виде Wi-Fi по стандарту 802.11, Bluetooth и сотовой связи. Уровень преобразует единицы и нули в сигнал и обратно.

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

Канальный уровень

Уровнем выше принятые биты собираются в кадры (frames) и передаются между устройствами, находящимися внутри одной локальной сети. Здесь работают Ethernet (стандарт IEEE 802.3) и Wi-Fi (IEEE 802.11), а для соединений «точка-точка» PPP.

У каждого сетевого интерфейса есть MAC-адрес — идентификатор, заданный производителем. Программа знает IP-адрес получателя, а отправить кадр необходимо на MAC-адрес; соответствие между ними выясняет протокол ARP, опрашивая локальную сеть. В институтских сетях встречается VLAN — логическое разделение одной физической сети на независимые сегменты, не видящие друг друга, чтобы, например, сеть управления установкой не пересекалась с офисной.

Просмотреть состояние этого уровня можно следующими командами.

ip link show          # список сетевых интерфейсов и их состояние
ethtool eth0          # скорость, режим дуплекса, статистика ошибок
arp -a                # таблица соответствия IP-адресов и MAC-адресов

Сетевой уровень

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

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

Адресация

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

Часть диапазонов зарезервирована под частные сети: их адреса не маршрутизируются в интернет и могут повторяться в разных организациях:

• 10.0.0.0/8 для больших корпоративных сетей;
• 172.16.0.0/12 для сетей средних размеров;
• 192.168.0.0/16 для домашних роутеров.

Запись вида /24 после адреса называется префиксом и указывает, сколько старших битов адреса отведено под номер сети. Запись 192.168.1.0/24 описывает сеть из 256 адресов, различающихся только последним октетом.

IPv6 решает проблему нехватки адресов. Адрес занимает 128 бит и записывается восемью группами по четыре шестнадцатеричные цифры, как 2001:0db8:85a3:0000:0000:8a2e:0370:7334. Длинные цепочки нулей разрешено сокращать двойным двоеточием, и записанный выше адрес превращается в 2001:db8:85a3::8a2e:370:7334.

Маршрутизация

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

$ ip route show
default via 192.168.1.1 dev eth0
192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.100
10.0.0.0/8 via 192.168.1.254 dev eth0

Выбирается всегда самая конкретная из подходящих строк. Пакет в сеть 192.168.1.0/24 уходит непосредственно в интерфейс eth0, пакет в 10.0.0.0/8 идёт через шлюз 192.168.1.254, а всё, не подошедшее ни под одну строку, попадает в default. Когда сервер соседнего корпуса не отвечает, а до машины, стоящей в той же комнате, ping проходит, проверять нужно именно здесь: чаще всего до нужной сети отсутствует маршрут.

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

$ ip rule
0:    from all lookup local
32766: from all lookup main
32767: from all lookup default

Когда маршрут есть, а пакеты не доходят, требуется выяснить, где они теряются. ip route get показывает маршрут, выбираемый ядром для конкретного адреса; traceroute перечисляет узлы на пути пакета; mtr делает то же непрерывно и подсчитывает потери на каждом переходе — так проще всего показать сетевым администраторам, на каком узле происходит разрыв:

traceroute 8.8.8.8
mtr 8.8.8.8
ip route get 8.8.8.8

Транспортный уровень

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

UDP: быстро и без гарантий

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

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

TCP: надёжно, но дороже

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

Соединение открывается тройным рукопожатием:

1. клиент отправляет серверу SYN, означающий «хочу соединиться»;
2. сервер отвечает SYN-ACK, означающим «согласен, и я тоже хочу»;
3. клиент отвечает ACK, то есть «принято». Соединение, установленное так, готово к передаче.

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

Гарантии TCP основаны на полях его заголовка.

| Порт отправителя      | Порт получателя       |
| Номер последовательности (Sequence Number)    |
| Номер подтверждения (Acknowledgment Number)   |
| Смещение | Резерв | Флаги | Размер окна      |
| Контрольная сумма     | Указатель срочности   |

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

Контроль перегрузок

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

• Tahoe и Reno, классические алгоритмы, реагирующие на потерянный пакет резким снижением скорости;
• CUBIC, установленный в Linux по умолчанию, восстанавливает потерянную скорость агрессивнее;
• BBR, современный подход от Google, вместо потерь ориентируется на измеренную полосу и задержку, что заметно лучше работает на длинных линиях между городами.

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

Просмотреть состояние открытых соединений можно следующими командами.

ss -tn                      # открытые TCP-соединения
ss -tlnp                    # какие порты слушают и какие процессы
tcpdump -i any tcp port 80  # перехват пакетов на порту 80

Прикладной уровень

На прикладном уровне работают сами программы и их протоколы: DNS переводит имена в адреса, HTTP переносит данные, TLS их шифрует.

DNS: из имён в адреса

Компьютеры адресуют друг друга числами, а люди именами. Связывает их система доменных имён — распределённая база, возвращающая по имени example.com его IP-адрес.

Чаще всего встречаются четыре типа записей:

Из Python имя разрешается одной строкой.

import socket

ip_address = socket.gethostbyname("example.com")

DNS является самым частым источником жалоб «ничего не работает». Прежде чем искать ошибку в собственной программе, необходимо проверить командой dig example.com или nslookup example.com, разрешается ли имя вообще.

URL: адрес ресурса

Адрес, вводимый в браузер, устроен по единой схеме.

протокол://хост:порт/путь?запрос#якорь
   https :// api.example.com : 443 /v1/data ?limit=10 #results

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

Схем существует много, и не все они относятся к вебу: https://api.example.com/v1/data, ftp://ftp.example.com/files, mailto:user@example.com.

HTTP: обмен с сервером

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

HTTP-запрос

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

GET /index.html HTTP/1.1
Host: example.com
User-Agent: Mozilla/5.0
Accept: text/html
Connection: keep-alive

Первое слово запроса — метод, он сообщает серверу, что требуется сделать с ресурсом:

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

Ответ сервера

Ответ устроен так же и содержит статусную строку, заголовки и тело:

HTTP/1.1 200 OK
Content-Type: text/html
Content-Length: 1234
Server: nginx
Date: Mon, 21 Nov 2022 00:18:53 GMT

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

При 4xx повторять запрос бессмысленно, пока клиент не исправит его сам; при 5xx имеет смысл подождать и повторить попытку.

Работа с HTTP в Python

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

Использование сокетов

Открывается сокет, в него записываются две строки запроса, читается ответ.

import socket

# TCP-соединение
with socket.socket(socket.AF_INET, socket.SOCK_STREAM) as sock:
    sock.connect(('example.com', 80))
    request = b'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n'
    sock.sendall(request)
    response = sock.recv(4096)

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

Библиотека requests

requests берёт на себя соединения, редиректы, кодировки и разбор JSON.

import requests

response = requests.get('https://api.example.com/data')
print(response.status_code)
print(response.headers)
print(response.json())

В коде, работающем ночью без присмотра, добавляют timeout= к каждому запросу — без него зависший сервер остановит сбор данных навсегда — и повтор с нарастающей паузой при ошибках 5xx, чтобы временный отказ сервера не стоил ночи работы.

TLS: буква S в HTTPS

Обычный HTTP передаёт всё открытым текстом, включая пароли и токены; любой узел на пути видит содержимое. TLS (прежде SSL) добавляет к соединению шифрование и проверку подлинности сервера по сертификату: браузер убеждается, что взаимодействует с тем сайтом, за который тот себя выдаёт.

В Python шифрование добавляется обёрткой поверх обычного сокета.

import ssl
import socket

context = ssl.create_default_context()
with socket.create_connection(('example.com', 443)) as sock:
    with context.wrap_socket(sock, server_hostname='example.com') as ssock:
        ssock.sendall(b'GET / HTTP/1.1\r\nHost: example.com\r\n\r\n')
        response = ssock.recv(4096)

Веб-скрапинг и парсинг HTML

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

Библиотека BeautifulSoup

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

from bs4 import BeautifulSoup
import requests

html = requests.get('http://example.com').text
soup = BeautifulSoup(html, 'html.parser')

# Извлечение данных
title = soup.find('title').text
links = soup.find_all('a', href=True)
for link in links:
    print(link['href'], link.text)

Корректный скрапинг

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

1. Необходимо ознакомиться с robots.txt, файлом в корне сайта, где владелец указывает, что разрешено обходить роботам, а что нет. Технически он ничего не запрещает — это договорённость, но нарушать её не следует.
2. Между запросами необходимы паузы. Сотня запросов в секунду с одного адреса неотличима от атаки и приводит к блокировке.
3. Программа должна представляться в заголовке User-Agent. Следует указать, что это за программа и как связаться с её автором: администратору, читающему логи, это упрощает работу, а автору снижает вероятность блокировки.
4. Ошибки должны обрабатываться. Сеть ненадёжна, и код должен переживать таймаут, 503 и изменившуюся вёрстку, а не завершаться посреди ночного сбора данных.
5. Скачанное кешируется. Повторный запуск разбора не должен снова загружать те же страницы: так и быстрее, и корректнее по отношению к серверу.

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

Работа с API

Если у источника есть API, взаимодействие ведётся на языке данных: запрос с параметрами, ответ в JSON, оговорённый набор полей вместо вёрстки, переделываемой при каждой смене дизайна. Как сервисы договариваются между собой и что в таком договоре нарушается, когда сервисов становится много, подробно рассмотрено у Клеппмана [16].

Публичные API

Устроены такие интерфейсы одинаково независимо от того, что они отдают, курсы валют, переводы слов или каталог наблюдений: адрес сервиса, словарь параметров и ключ доступа. Пример — словарь Яндекса:

import requests
import json

# Пример работы с API словаря
DICTIONARY_API = 'https://dictionary.yandex.net/api/v1/dicservice.json/lookup'
params = {
    'key': 'your_api_key',
    'lang': 'en-ru',
    'text': 'hello'
}

response = requests.get(DICTIONARY_API, params=params)
data = response.json()
translations = data['def'][0]['tr']

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

OAuth авторизация

Когда речь идёт о личных данных пользователя, простого ключа недостаточно. OAuth описывает схему, при которой пользователь не передаёт программе свой пароль. Вместо него сервис выдаёт ей токен, ограниченный по правам и по времени и отзываемый в любой момент. Токен прикладывается к каждому запросу в заголовке Authorization:

class ApiClient:
    def __init__(self, token):
        self.session = requests.Session()
        self.session.headers['Authorization'] = f'Bearer {token}'
    
    def get_user_info(self):
        response = self.session.get('https://api.example.com/user')
        return response.json()

requests.Session() хранит заголовки между запросами и переиспользует открытое TCP-соединение, поэтому серия обращений к одному серверу выполняется заметно быстрее, чем столько же отдельных вызовов requests.get.

JSON формат

JavaScript Object Notation — текстовый формат обмена данными, почти взаимно однозначно соответствующий словарям и спискам Python.

import json

# Сериализация
data = {'name': 'John', 'age': 30}
json_string = json.dumps(data)

# Десериализация
parsed_data = json.loads(json_string)

В стандарте JSON нет ни NaN, ни бесконечностей. json.dumps запишет их как NaN и Infinity, однако это уже не JSON, и чужой разборщик на такой строке завершится ошибкой. Пропуски в измерениях надёжнее кодировать явным null.

Асинхронные HTTP-запросы

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

Библиотека httpx

httpx повторяет интерфейс requests, но поддерживает оба режима, синхронный и асинхронный, так что при переходе код почти не переписывается:

import asyncio

import httpx

# Синхронные запросы
with httpx.Client() as client:
    response = client.get('https://example.com')
    print(response.status_code)

# Асинхронные запросы
async def fetch_data():
    async with httpx.AsyncClient() as client:
        response = await client.get('https://example.com')
        return response.json()

print(asyncio.run(fetch_data()))

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

Резюме

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

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

Бессмысленно отлаживать код запроса, если имя сервера не разрешается, и проверять DNS, если не поднят сетевой интерфейс.

Из инструментов Python достаточно двух: requests для обычных запросов и httpx там, где требуется асинхронность. Сокеты необходимы для понимания того, что происходит под библиотеками.

Задание. Поставить перед приложением nginx и выяснить, почему запрос не доходит: «Деплой стартапа „Котики в мир“».

Базы данных

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

Ограничения хранения в файлах

Хранение данных в лаборатории почти всегда развивается по одному сценарию. Сначала появляется result.csv. Затем result_final.csv, result_final_v2.csv и папка 2026-08-20/ с двадцатью файлами, названными по энергии пучка, номеру захода и фамилии оператора. Через год накапливаются десятки гигабайт CSV-файлов, и вопрос «показать все измерения канала BPM01 при энергии выше 10 МэВ» превращается в вечер работы со скриптом, рекурсивно обходящим папки и разбирающим имена файлов.

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

• Конкурентный доступ. Скрипт сбора данных записывает файл, а исследователь в этот момент открывает его для анализа и читает недописанную строку. Два процесса записывают одновременно, и файл оказывается повреждённым.
• Целостность. CSV не проверяет ничего. В столбец с температурой попадает строка "error", порядок столбцов от файла к файлу различается, а измерение ссылается на заход, удалённый кем-то вместе с папкой.
• Поиск. Чтобы найти нужные записи, приходится читать все файлы целиком в память. На миллионах записей это занимает минуты; при правильно организованных данных тот же запрос выполняется за миллисекунды.

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

Реляционная модель

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

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

experiments ──< runs ──< measurements
   (1)          (N)          (N)

• experiments описывает кампанию, её название, установку и дату начала;
• runs описывает заход, его кампанию, номер, энергию пучка и оператора;
• measurements описывает отдельную точку, её заход, канал, время и значение.

Знак ──< читается как связь «один ко многим»: у одной кампании много заходов, а у одного захода много снятых точек.

Ключи и связи

Первичным ключом (primary key) называется столбец или набор столбцов, однозначно идентифицирующий строку. Обычно это суррогатный целочисленный id, выдаваемый базой самостоятельно.

Внешним ключом (foreign key) называется столбец, ссылающийся на первичный ключ другой таблицы. runs.experiment_id хранит id кампании, и таким образом строки связываются между собой. СУБД следит за валидностью ссылки: нельзя вставить заход с experiment_id = 42, если кампании с таким id нет, и нельзя удалить кампанию, на которую ссылаются заходы.

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

Нормализация

Соблазнительно поместить всё в одну широкую таблицу, повторяя в каждой строке измерения название кампании, энергию и фамилию оператора. Такая схема работает до первой правки. Если оператор оказался «Ивановым», а не «Ивановым А.», обновлять приходится миллион строк, а при сбое скрипта на середине данные остаются противоречивыми. Это явление называется аномалиями обновления.

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

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

Основы SQL на примере SQLite

SQL (Structured Query Language) — декларативный язык для реляционных баз. Пользователь описывает нужный результат, а СУБД самостоятельно решает, как его получить.

Изучение ведётся на SQLite, встраиваемой СУБД без сервера: вся база лежит в одном файле, а драйвер входит в стандартную библиотеку Python (модуль sqlite3). При этом SQLite остаётся полноценной реляционной СУБД с транзакциями, работающей с базами в десятки гигабайт. Для лабораторных данных этого достаточно.

Открыть консоль SQLite можно командой sqlite3 lab.db, которая создаёт файл самостоятельно, а просмотреть базу в графическом интерфейсе позволяет программа DB Browser for SQLite.

CREATE TABLE: создание таблиц

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

CREATE TABLE experiments (
    id         INTEGER PRIMARY KEY,   -- первичный ключ, база выдаёт сама
    name       TEXT NOT NULL UNIQUE,  -- название кампании, без повторов
    setup      TEXT,                  -- описание установки
    started_at TEXT NOT NULL          -- дата в ISO-формате: '2026-08-20'
);

CREATE TABLE runs (
    id            INTEGER PRIMARY KEY,
    experiment_id INTEGER NOT NULL REFERENCES experiments(id),  -- внешний ключ
    run_number    INTEGER NOT NULL,
    energy_mev    REAL NOT NULL,      -- энергия пучка в заходе, МэВ
    operator      TEXT,
    started_at    TEXT NOT NULL,
    UNIQUE (experiment_id, run_number)  -- номер захода уникален внутри кампании
);

CREATE TABLE measurements (
    id      INTEGER PRIMARY KEY,
    run_id  INTEGER NOT NULL REFERENCES runs(id),
    channel TEXT NOT NULL,            -- имя канала: 'BPM01', 'T_magnet', ...
    t       REAL NOT NULL,            -- время от начала захода, с
    value   REAL NOT NULL             -- измеренное значение
);

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

Внешние ключи SQLite проверяет только при явно включённой проверке, и включать её необходимо в каждом новом соединении:

PRAGMA foreign_keys = ON;

Без этой строки вставка ссылки на несуществующую кампанию пройдёт без ошибок, и база незаметно накопит нарушенные связи. PostgreSQL и MySQL проверяют внешние ключи по умолчанию, однако MySQL без предупреждения игнорирует объявленные ключи в таблицах MyISAM, а сессионная переменная foreign_key_checks=0, выставляемая всеми дампами mysqldump, снимает проверку и в InnoDB.

INSERT: вставляем данные

Заполняемые базой столбцы перечислять не требуется: id она выдаст очередной. experiment_id для захода необходимо указать, иначе неизвестно, к какой кампании он относится.

INSERT INTO experiments (name, setup, started_at)
VALUES ('Калибровка датчиков положения', 'стенд ЛИУ', '2026-08-20');

INSERT INTO runs (experiment_id, run_number, energy_mev, operator, started_at)
VALUES (1, 1, 12.5, 'Иванов', '2026-08-20T10:15:00');

-- несколько строк одним запросом
INSERT INTO measurements (run_id, channel, t, value) VALUES
    (1, 'BPM01',    0.0, 0.412),
    (1, 'BPM01',    0.1, 0.418),
    (1, 'T_magnet', 0.0, 42.3);

Последняя форма, со списком кортежей после VALUES, вставляет группу строк одним запросом; для тысячи точек с АЦП это на порядки быстрее тысячи отдельных INSERT; причина рассматривается в разделе про транзакции.

SELECT: выборка

Вопрос, требовавший вечера работы со скриптом-обходчиком папок, записывается в три строки:

-- все точки канала BPM01 из первого захода, по возрастанию времени
SELECT t, value
FROM measurements
WHERE run_id = 1 AND channel = 'BPM01'
ORDER BY t;

-- десять последних заходов с энергией выше 10 МэВ
SELECT run_number, energy_mev, started_at
FROM runs
WHERE energy_mev > 10
ORDER BY started_at DESC
LIMIT 10;

WHERE фильтрует строки, ORDER BY сортирует отобранное (DESC задаёт убывание), LIMIT ограничивает результат. Звёздочка SELECT * возвращает все столбцы, что удобно в консоли, однако в скриптах нужные столбцы перечисляются явно.

JOIN: соединение таблиц

Нормализация разложила данные по трём таблицам, а JOIN собирает разложенное обратно. Соединение сопоставляет строки по условию, обычно «внешний ключ равен первичному»:

-- каждая точка вместе с номером захода и названием кампании
SELECT e.name, r.run_number, m.t, m.value
FROM measurements AS m
JOIN runs        AS r ON r.id = m.run_id
JOIN experiments AS e ON e.id = r.experiment_id
WHERE m.channel = 'BPM01'
ORDER BY e.name, r.run_number, m.t;

AS m задаёт псевдоним, избавляющий от длинных имён. Кроме обычного (внутреннего) JOIN существует LEFT JOIN, сохраняющий строки левой таблицы даже при отсутствии пары справа. Таким образом находят заходы без измерений.

GROUP BY: агрегация

Агрегатные функции (COUNT, AVG, SUM, MIN, MAX) сворачивают отобранную группу строк в одно число, а GROUP BY задаёт признак группировки:

-- сводка по каждому заходу: число точек и статистика сигнала
SELECT r.run_number,
       r.energy_mev,
       COUNT(*)     AS n_points,
       AVG(m.value) AS mean_value,
       MIN(m.value) AS min_value,
       MAX(m.value) AS max_value
FROM measurements AS m
JOIN runs AS r ON r.id = m.run_id
WHERE m.channel = 'BPM01'
GROUP BY r.id
HAVING COUNT(*) >= 100   -- отбрасываем слишком короткие заходы
ORDER BY r.energy_mev;

HAVING фильтрует после группировки, по вычисленным агрегатам; WHERE отбирает строки до неё.

Индексы: ускорение поиска

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

CREATE INDEX idx_measurements_run_channel
ON measurements (run_id, channel);

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

Тот же SQL из Python

Модуль sqlite3, входящий в стандартную библиотеку, устанавливать не требуется.

import sqlite3

# открываем (или создаём) файл базы; ":memory:" — временная база в памяти
con = sqlite3.connect("lab.db")

# в SQLite проверка внешних ключей по умолчанию выключена — включаем
con.execute("PRAGMA foreign_keys = ON")

cur = con.cursor()  # курсор выполняет запросы и отдаёт результаты

# создаём таблицу, если её ещё нет (текст запроса — тот же SQL)
cur.execute("""
    CREATE TABLE IF NOT EXISTS measurements (
        id      INTEGER PRIMARY KEY,
        run_id  INTEGER NOT NULL,
        channel TEXT NOT NULL,
        t       REAL NOT NULL,
        value   REAL NOT NULL
    )
""")

# одиночная вставка: значения передаём кортежем, в запросе — знаки вопроса
cur.execute(
    "INSERT INTO measurements (run_id, channel, t, value) VALUES (?, ?, ?, ?)",
    (1, "BPM01", 0.0, 0.412),
)

# массовая вставка: executemany принимает любой итерируемый объект;
# read_adc() здесь — пользовательская функция опроса АЦП
points = [(1, "BPM01", 0.1 * i, read_adc()) for i in range(1000)]
cur.executemany(
    "INSERT INTO measurements (run_id, channel, t, value) VALUES (?, ?, ?, ?)",
    points,
)
con.commit()  # фиксируем изменения на диске

# выборка: по курсору можно итерироваться, каждая строка — кортеж
for t, value in cur.execute(
    "SELECT t, value FROM measurements WHERE channel = ? ORDER BY t",
    ("BPM01",),
):
    print(t, value)

con.close()

Для небольших выборок удобны cur.fetchone() и cur.fetchall(), однако итерация по курсору экономнее: строки читаются по мере надобности и не оседают в памяти все сразу.

Параметризованные запросы и SQL-инъекции

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

channel = input("Канал: ")

# ТАК ДЕЛАТЬ НЕЛЬЗЯ: запрос склеивается из чужого текста
cur.execute(f"SELECT t, value FROM measurements WHERE channel = '{channel}'")

Если пользователь введёт ' OR '1'='1, итоговый запрос превратится в ... WHERE channel = '' OR '1'='1', где условие всегда истинно, фильтр исчезает, а наружу утекает вся таблица. Ввод вида '; DROP TABLE measurements; -- в СУБД, чей драйвер исполняет несколько команд подряд, уничтожит таблицу. Это явление называется SQL-инъекцией, одной из самых старых и до сих пор распространённых уязвимостей (см. xkcd про школьника Bobby Tables).

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

# правильно: запрос отдельно, данные отдельно
cur.execute("SELECT t, value FROM measurements WHERE channel = ?", (channel,))

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

Транзакции и ACID

Транзакция — группа запросов, выполняемая как единое целое: применяются либо все, либо ни один. Её гарантии описывает аббревиатура ACID:

• Atomicity (атомарность) означает неделимость транзакции: сбой, случившийся на середине, откатывает всё сделанное;
• Consistency (согласованность) требует, чтобы база переходила из одного корректного состояния в другое, не нарушая ограничений (ключи, NOT NULL, UNIQUE);
• Isolation (изолированность) скрывает промежуточные состояния, возникающие в параллельных транзакциях, друг от друга;
• Durability (долговечность) сохраняет подтверждённые (COMMIT) данные даже при внезапном отключении питания.

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

def save_run(con, run_row, points):
    """Сохраняет заход и все его измерения одной транзакцией."""
    cur = con.cursor()
    try:
        # первый INSERT неявно открывает транзакцию
        cur.execute(
            "INSERT INTO runs "
            "(experiment_id, run_number, energy_mev, started_at) "
            "VALUES (?, ?, ?, ?)",
            run_row,
        )
        run_id = cur.lastrowid  # id только что вставленной строки
        cur.executemany(
            "INSERT INTO measurements (run_id, channel, t, value) "
            "VALUES (?, ?, ?, ?)",
            [(run_id, ch, t, v) for ch, t, v in points],
        )
        con.commit()    # всё получилось — фиксируем
    except sqlite3.Error:
        con.rollback()  # любая ошибка — откатываем целиком
        raise

Ту же пару commit/rollback обеспечивает конструкция with con:, подтверждающая транзакцию при выходе из блока и откатывающая её при исключении. Транзакции ускоряют и массовую вставку: миллион INSERT с commit после каждого означает миллион синхронизаций с диском, а те же вставки в одной транзакции выполняются на порядки быстрее.

SQLite, PostgreSQL или MySQL

Три реляционные СУБД, чаще всего встречающиеся в лаборатории, различаются не языком запросов (SQL везде почти один и тот же), а тем, кто и каким образом получает доступ к базе.

Если данные лежат на локальном диске и работают с ними один исследователь и его скрипты, то выбирается SQLite. Если база нужна нескольким людям или сервисам по сети, если в неё пишут одновременно и требуются права доступа, то предпочтительнее PostgreSQL [17]: сегодня это выбор по умолчанию для серверной СУБД. MySQL чаще достаётся как данность вместе с унаследованным проектом или хостингом, чем выбирается осознанно для новой системы.

ORM: SQLAlchemy

SQL в виде строк внутри Python-кода не проверяется до запуска, результаты приходят кортежами, а логика, связывающая объект с его окружением, оказывается распределённой по запросам. ORM (Object-Relational Mapping) отображает таблицы на классы, строки на объекты, а внешние ключи на атрибуты-связи. Стандартом де-факто в Python является SQLAlchemy.

from sqlalchemy import ForeignKey, create_engine, select
from sqlalchemy.orm import (
    DeclarativeBase, Mapped, mapped_column, relationship, Session,
)

class Base(DeclarativeBase):
    pass

class Run(Base):
    __tablename__ = "runs"

    id: Mapped[int] = mapped_column(primary_key=True)
    energy_mev: Mapped[float]
    # связь "один ко многим": у захода — список измерений
    measurements: Mapped[list["Measurement"]] = relationship(
        back_populates="run"
    )

class Measurement(Base):
    __tablename__ = "measurements"

    id: Mapped[int] = mapped_column(primary_key=True)
    run_id: Mapped[int] = mapped_column(ForeignKey("runs.id"))
    channel: Mapped[str]
    value: Mapped[float]
    run: Mapped[Run] = relationship(back_populates="measurements")

engine = create_engine("sqlite:///lab.db")  # та же база, поменяется только URL
Base.metadata.create_all(engine)            # создаёт таблицы по классам

with Session(engine) as session:
    # объекты вместо INSERT: связи расставляются сами
    run = Run(energy_mev=12.5)
    run.measurements.append(Measurement(channel="BPM01", value=0.412))
    session.add(run)
    session.commit()

    # запрос вместо SELECT ... JOIN: строится из Python-выражений
    stmt = select(Measurement).join(Run).where(Run.energy_mev > 10)
    for m in session.execute(stmt).scalars():
        print(m.channel, m.value, m.run.energy_mev)

Смена SQLite на PostgreSQL сводится к правке одной строки в create_engine; остальной код не изменяется.

ORM оправдан в приложении с десятком связанных таблиц и развивающейся схемой (накопленные миграции удобно вести инструментом Alembic), при командной разработке и множестве типовых операций «создать-прочитать-обновить-удалить». Чистый SQL предпочтителен для аналитических запросов с многоуровневыми агрегатами и оконными функциями (SQL здесь короче ORM-конструкций), для массовых загрузок и разовых скриптов. ORM не освобождает от знания SQL: он генерирует тот же SQL, и когда запрос выполняется медленно, разбираться приходится со сгенерированным текстом (для этого достаточно включить create_engine(..., echo=True) и просмотреть запросы, уходящие в базу).

Нереляционные базы данных

Под конкретные профили нагрузки существуют специализированные базы, объединяемые общим названием «NoSQL». Их устройство и цена каждого компромисса подробно рассмотрены у Клеппмана [16].

Проще всех устроено хранилище пар «ключ → значение», Redis. Оно располагается в оперативной памяти, и операции занимают микросекунды. Типичные роли: кеш (результат тяжёлого запроса или расчёта помещается под ключ с заданным временем жизни), очереди задач между процессами (на Redis работают брокеры для Celery), счётчики и pub/sub-уведомления. Запись на диск включается по желанию. Redis отвечает за скорость, а не за главное хранилище истины; типичные приёмы собраны у Карлсона [19].

Там, где у записей нет общей структуры, применяют документные базы наподобие MongoDB. Единицей хранения служит документ, вложенная структура наподобие JSON; документы собираются в коллекции, и жёсткой схемы нет, поэтому соседние документы могут иметь разные поля. Это удобно для разнородных метаданных, меняющих структуру от записи к записи. «Отсутствие схемы» означает, что схема находится не в базе, а в коде, и проверять её также приходится разработчику. Практические следствия рассмотрены в руководстве по MongoDB [18].

Телеметрию установки (давление в вакуумной камере, токи магнитов, температуры), приходящую с сотен датчиков каждую секунду годами, в ускорительной технике называют slow control и хранят в базах временных рядов. InfluxDB предназначена для потока «метка времени → значение» с тегами. Такие базы позволяют автоматически прореживать и удалять устаревшие данные (retention policies), быстро агрегировать по окнам времени («среднее за каждую минуту последних суток») и стыкуются с Grafana для дашбордов мониторинга. В мире PostgreSQL то же обеспечивает расширение TimescaleDB.

Наконец, для аналитики на миллиардах записей созданы колоночные базы, самая известная из которых называется ClickHouse. Она хранит данные не по строкам, а по столбцам. Значения одного столбца располагаются рядом, хорошо сжимаются, и запрос «среднее value по миллиарду строк» читает с диска только нужные столбцы, укладываясь в секунды на обычном сервере вместо часов; диалект SQL привычный. Платой является слабость в точечных обновлениях и удалениях: колоночные базы рассчитаны на дозапись и анализ, а не на правку отдельных строк.

Выбор хранилища: пример реальной системы

Система хранения данных ускорительного комплекса использует сразу три базы. Такой подход называется полиглотным хранением (polyglot persistence): под каждый профиль данных выбирается своё хранилище.

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

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

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

Выбор сводится к одному признаку на каждую базу.

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

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

Одна задача в четырёх хранилищах

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

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

Сервис написан на микрофреймворке Flask: декоратор @app.route привязывает функцию к URL и методу, объект request даёт доступ к параметрам и телу запроса. Заголовочная часть общая для всех вариантов и далее не повторяется.

import json
from contextlib import closing

import psycopg2
import redis
from flask import Flask, request

app = Flask(__name__)

FILE_PATH = 'data.txt'
PAGE_SIZE = 20
ELEMENT_SIZE = 64
FILL_CHAR = b' '
TTL = 60
postgres_creds = {'dbname': 'lab', 'host': 'localhost'}
redis_creds = {'host': 'localhost', 'port': 6379}

Наивное решение. GET

Самый прямолинейный вариант — обычный текстовый файл, по строке на запись. Чтобы отдать одну страницу, приходится прочитать весь файл, а при изменении и удалении ещё и переписать его заново: \(O(n)\) на каждую операцию.

@app.route('/', methods=['GET'])
def paginated_get():
    page = int(request.args.get('page', '0'))
    first = page * PAGE_SIZE
    last = first + PAGE_SIZE
    result = []
    with open(FILE_PATH, 'r') as f:
        for i, line in enumerate(f.readlines()[first:last]):
            result.append({'id': first + i, 'data': line.strip()})
    return {"result": result}

Наивное решение. POST

@app.route('/', methods=['POST'])
def post():
    data = request.json['data']
    with open(FILE_PATH, 'a') as f:
        f.write(data + '\n')
    return {}, 201

Наивное решение. PUT

@app.route('/<int:data_id>', methods=['PUT'])
def put(data_id):
    data = request.json['data']
    with open(FILE_PATH, 'r') as f:
        new_data = f.readlines()
        new_data[data_id] = data + '\n'
    with open(FILE_PATH, 'w') as f:
        f.writelines(new_data)
    return {}, 204

Наивное решение. DELETE

@app.route('/<int:data_id>', methods=['DELETE'])
def delete(data_id):
    with open(FILE_PATH, 'r') as f:
        new_data = f.readlines()
    del new_data[data_id]
    with open(FILE_PATH, 'w') as f:
        f.writelines(new_data)
    return {}, 204

Фиксированные записи. GET

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

@app.route('/', methods=['GET'])
def paginated_get():
    page = int(request.args.get('page', '0'))
    first = page * PAGE_SIZE
    result = []
    with open(FILE_PATH, 'rb') as f:
        f.seek(first * ELEMENT_SIZE)
        data = f.read(PAGE_SIZE * ELEMENT_SIZE)
        for i in range(PAGE_SIZE):
            result.append(
                {
                    "id": first + i,
                    "data": (
                        data[i * ELEMENT_SIZE: (i + 1) * ELEMENT_SIZE].
                        strip(FILL_CHAR).decode('utf-8')
                    )
                }
            )
    return {"result": result}

Фиксированные записи. POST

@app.route('/', methods=['POST'])
def post():
    data = str(request.json['data'])
    with open(FILE_PATH, 'a+b') as f:
        f.write(data.encode('utf-8').ljust(ELEMENT_SIZE, FILL_CHAR))
    return {}, 201

Фиксированные записи. PUT

@app.route('/<int:data_id>', methods=['PUT'])
def put(data_id):
    data = request.json['data']
    with open(FILE_PATH, 'r+b') as f:
        f.seek(data_id * ELEMENT_SIZE)
        f.write(data.encode('utf-8').ljust(ELEMENT_SIZE, FILL_CHAR))
    return {}, 204

Фиксированные записи. DELETE

@app.route('/<int:data_id>', methods=['DELETE'])
def delete(data_id):
    with open(FILE_PATH, 'r+b') as f:
        point = data_id * ELEMENT_SIZE
        f.seek(point)
        while True:
            f.seek(point + ELEMENT_SIZE)
            complex_data = f.read(ELEMENT_SIZE)
            f.seek(point)
            if len(complex_data):
                f.write(complex_data)
                point += ELEMENT_SIZE
            else:
                f.truncate()
                break
    return {}, 204

Реляционная база. GET

База данных скрывает эту механику за индексами: поиск по ключу, вставку и удаление она выполняет не хуже структур данных из главы «Основные структуры данных».

@app.route('/', methods=['GET'])
def paginated_get():
    page = int(request.args.get('page', '0'))
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'SELECT "id", "todo" FROM "todos" '
                'ORDER BY "id" OFFSET %s LIMIT %s;',
                (page * PAGE_SIZE, PAGE_SIZE)
            )
            return {
                "result": [{"id": row[0], "data": row[1]} for row in cursor]
            }

Реляционная база. POST

@app.route('/', methods=['POST'])
def post():
    data = str(request.json['data'])
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'INSERT INTO "todos" ("todo") VALUES (%s) RETURNING "id";',
                (data,)
            )
            conn.commit()
            return {"id": cursor.fetchone()[0]}, 201

Реляционная база. PUT

@app.route('/<int:data_id>', methods=['PUT'])
def put(data_id):
    data = request.json['data']
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'UPDATE "todos" SET "todo" = %s WHERE "id" = %s;',
                (data, data_id)
            )
            conn.commit()
            return {}, 204

Реляционная база. DELETE

@app.route('/<int:data_id>', methods=['DELETE'])
def delete(data_id):
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'DELETE FROM "todos" WHERE "id" = %s;',
                (data_id,)
            )
            conn.commit()
            return {}, 204

Кеш. GET

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

@app.route('/', methods=['GET'])
def paginated_get():
    page = int(request.args.get('page', '0'))

    redis_client = redis.Redis(**redis_creds)
    cached_page = redis_client.get(page)

    if cached_page:
        return cached_page

    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'SELECT "id", "todo" FROM "todos" '
                'ORDER BY "id" OFFSET %s LIMIT %s;',
                (page * PAGE_SIZE, PAGE_SIZE)
            )
            result = json.dumps({
                "result": [{"id": row[0], "data": row[1]} for row in cursor]
            })
            redis_client.set(page, result, ex=TTL)
            return result

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

Кеш. POST

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

@app.route('/', methods=['POST'])
def post():
    data = str(request.json['data'])
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'INSERT INTO "todos" ("todo") VALUES (%s) RETURNING "id";',
                (data,)
            )
            conn.commit()
            new_id = cursor.fetchone()[0]

    redis_client = redis.Redis(**redis_creds)
    cached_pages = redis_client.keys()  # в кеше лежат только страницы
    if cached_pages:
        redis_client.delete(*cached_pages)
    return {"id": new_id}, 201

Кеш. PUT

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

@app.route('/<int:data_id>', methods=['PUT'])
def put(data_id):
    data = request.json['data']
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'UPDATE "todos" SET "todo" = %s WHERE "id" = %s;',
                (data, data_id)
            )
            cursor.execute(
                'SELECT count(*) FROM "todos" WHERE "id" < %s;',
                (data_id,)
            )
            page = cursor.fetchone()[0] // PAGE_SIZE
            conn.commit()

    redis_client = redis.Redis(**redis_creds)
    redis_client.delete(page)
    return {}, 204

Кеш. DELETE

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

@app.route('/<int:data_id>', methods=['DELETE'])
def delete(data_id):
    with closing(psycopg2.connect(**postgres_creds)) as conn:
        with conn.cursor() as cursor:
            cursor.execute(
                'SELECT count(*) FROM "todos" WHERE "id" < %s;',
                (data_id,)
            )
            page = cursor.fetchone()[0] // PAGE_SIZE
            cursor.execute(
                'DELETE FROM "todos" WHERE "id" = %s;',
                (data_id,)
            )
            conn.commit()

    redis_client = redis.Redis(**redis_creds)
    stale = [key for key in redis_client.keys() if int(key) >= page]
    if stale:
        redis_client.delete(*stale)
    return {}, 204

Pandas и базы данных

Функция read_sql в pandas выполняет запрос и возвращает DataFrame, а to_sql записывает DataFrame в таблицу.

import pandas as pd
import sqlite3

con = sqlite3.connect("lab.db")

# фильтрация и агрегация выполняются в базе,
# в память попадает только готовая сводка
df = pd.read_sql(
    """
    SELECT r.energy_mev, AVG(m.value) AS mean_signal
    FROM measurements AS m
    JOIN runs AS r ON r.id = m.run_id
    WHERE m.channel = 'BPM01'
    GROUP BY r.id
    """,
    con,
)

# дальше — обычный pandas: график зависимости сигнала от энергии
df.plot.scatter(x="energy_mev", y="mean_signal")

# и обратно: результат анализа — в новую таблицу
df.to_sql("run_summary", con, if_exists="replace", index=False)

Тяжёлую фильтрацию и агрегацию следует передавать базе (SQL с WHERE и GROUP BY), а в pandas загружать свёрнутый результат: память и время расходуются на порядки экономнее, чем при чтении всех данных и фильтрации в DataFrame. Связка «SQL-запрос → DataFrame → график» даёт простейшее приложение для визуализации данных; построение графиков рассматривается в главах про обработку и визуализацию данных.

С чего начать в своей лаборатории

Рецепт перехода от тысячи CSV к одной базе включает следующие шаги:

1. Завести один файл lab.db и описать схему. Минимально необходимы таблицы вида experiments, runs, measurements с первичными и внешними ключами и NOT NULL на важных полях. Схема служит документацией, проверяющей сама себя.

2. Импортировать накопленные CSV одним скриптом:

   from pathlib import Path
   import pandas as pd
   import sqlite3
   
   con = sqlite3.connect("lab.db")
   
   for csv_path in Path("data").glob("**/*.csv"):
       df = pd.read_csv(csv_path)
       df["source_file"] = str(csv_path)  # не теряем происхождение данных
       df.to_sql("measurements_raw", con, if_exists="append", index=False)
   

   Далее «сырую» таблицу можно разложить по нормализованной схеме SQL-запросами.

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

4. Включить PRAGMA journal_mode=WAL: в этом режиме SQLite позволяет читать базу (строить графики) параллельно с записью.

5. Просматривать данные удобно в DB Browser for SQLite, а резервной копией служит обычная копия одного файла (Connection.backup() из Python выполняет её корректно даже во время работы).

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

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

• Документация SQLite
• SQLBolt, интерактивный учебник SQL с упражнениями
• Модуль sqlite3 в стандартной библиотеке Python
• PostgreSQL Tutorial
• Документация SQLAlchemy
• DB Browser for SQLite

Задание. Собрать и развернуть всё вместе, приложение, контейнеры, сеть и базу: «Деплой стартапа».

Научные библиотеки Python

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

Порядок изложения следует зависимостям. NumPy предоставляет быстрый многомерный массив, на котором основано всё остальное, и вместе с pandas, предназначенным для работы с таблицами, обеспечивает хранение и первичную обработку данных. SciPy надстраивает над массивом численные методы: интегрирование, решение уравнений, оптимизацию, подгонку кривых, обработку сигналов, преобразование Фурье. Почти всё, что физику приходится вычислять, там уже реализовано и проверено. Далее рассматривается построение графиков, где Matplotlib остаётся основным инструментом, а HoloViews устроен иначе: в нём описывается, какие данные имеются, а не способ их отрисовки, и библиотека сама выбирает подходящий вид графика, делая его интерактивным.

Завершается раздел машинным обучением, для которого всё перечисленное служит фундаментом.

Устройство языка — объекты, коллекции, функции и классы — рассматривалось в разделе «Язык Python». Здесь язык считается известным.

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

Почти весь код этой части набран в блокноте Jupyter — странице, разбитой на ячейки, где каждая ячейка выполняется отдельно и оставляет результат под собой, а имена, введённые в одной ячейке, сохраняются и доступны следующим. Строки, начинающиеся со знака процента, являются не кодом Python, а магическими командами IPython, оболочки, на которой работает блокнот. Одиночный % действует на строку, в которой стоит, так что %timeit sorted(data) измерит время этого вызова; двойной %%, поставленный первой строкой ячейки, распространяется на неё целиком, и %%timeit измерит всё написанное ниже. %load_ext подключает расширение IPython: с его помощью включается, например, построчный профилировщик, рассматриваемый в части «Ускорение расчётов». В обычном скрипте, запущенном через python file.py, ни одна из этих строк не работает, поэтому при переносе кода отсюда в файл их необходимо удалить.

NumPy и pandas

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

NumPy

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

Решением является NumPy. Идея заключается в том, чтобы хранить числа так, как их хранит C, то есть подряд, одного типа, без обёрток, а операции над ними передавать скомпилированному коду, работающему сразу над всем массивом. Выигрыш достигает сотен раз. На NumPy построен научный стек: SciPy, pandas, scikit-learn и библиотеки машинного обучения используют массивы NumPy.

Полная документация: numpy.org/doc.

NumPy решает две задачи:

• хранить многомерные массивы (в том числе матрицы);
• быстро считать математические функции сразу от всего массива.

Основой библиотеки является один объект, ndarray.

Отличия массива от списка:

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

Отсюда следуют две сильные стороны NumPy: векторизация и broadcasting.

import numpy as np

Способы создания массивов

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

Конвертация из структур Python

np.array([1, 2, 3, 4, 5])

array([1, 2, 3, 4, 5])

При конвертации можно задавать тип данных с помощью аргумента dtype:

np.array([1, 2, 3, 4, 5], dtype=np.float32)

array([1., 2., 3., 4., 5.], dtype=float32)

Аналогичное преобразование:

np.float32([1, 2, 3, 4, 5])

array([1., 2., 3., 4., 5.], dtype=float32)

Генерация массивов

• arange работает как аналог range из Python, но принимает и нецелочисленный шаг
• linspace равномерно разбивает отрезок на n-1 интервал
• logspace разбивает отрезок по логарифмической шкале
• zeros создаёт массив заданной размерности, заполненный нулями
• ones создаёт массив заданной размерности, заполненный единицами
• empty создаёт массив заданной размерности, не инициализированный никаким значением, то есть заполненный мусором из памяти

np.arange(0, 5, 0.5)

array([0. , 0.5, 1. , 1.5, 2. , 2.5, 3. , 3.5, 4. , 4.5])

np.linspace(0, 5, 11)

array([0. , 0.5, 1. , 1.5, 2. , 2.5, 3. , 3.5, 4. , 4.5, 5. ])

np.logspace(0, 9, 10, base=2)

array([  1.,   2.,   4.,   8.,  16.,  32.,  64., 128., 256., 512.])

np.zeros((2, 2))

array([[0., 0.],
       [0., 0.]])

np.ones((2, 2))

array([[1., 1.],
       [1., 1.]])

np.empty((2, 2))

array([[1., 1.],
       [1., 1.]])

np.diag([1,2,3])

array([[1, 0, 0],
       [0, 2, 0],
       [0, 0, 3]])

Размеры массива хранятся в поле shape, а число измерений — в поле ndim.

array = np.ones((2, 3,))
print('Размерность массива - %s, количество размерностей - %d'%(array.shape, array.ndim))
array

Размерность массива - (2, 3), количество размерностей - 2





array([[1., 1., 1.],
       [1., 1., 1.]])

## Чему равны ndim и shape в следующих случаях
print(np.diag([1,2,3]).shape, np.diag([1,2,3]).ndim)
print(np.zeros((5, 5, 5)).shape, np.zeros((5, 5, 5)).ndim)

(3, 3) 2
(5, 5, 5) 3

Метод reshape изменяет форму массива, не изменяя самих данных

array = np.arange(0, 6, 0.5)
array = array.reshape((2, 6))
array

array([[0. , 0.5, 1. , 1.5, 2. , 2.5],
       [3. , 3.5, 4. , 4.5, 5. , 5.5]])

Многомерный массив разворачивается в вектор функцией ravel

array = np.ravel(array)
array

array([0. , 0.5, 1. , 1.5, 2. , 2.5, 3. , 3.5, 4. , 4.5, 5. , 5.5])

# Какие будут массивы?
print(np.ravel(np.diag([1,2])))
print(np.reshape(np.diag([1,2]), [1, 4]))

[1 0 0 2]
[[1 0 0 2]]

Индексация

В NumPy применяется привычная индексация Python, включая отрицательные индексы и срезы, записываемые так же, как для списка

print(array[0])
print(array[-1])
print(array[1:-1])
print(array[1:-1:2])
print(array[::-1])

0.0
5.5
[0.5 1.  1.5 2.  2.5 3.  3.5 4.  4.5 5. ]
[0.5 1.5 2.5 3.5 4.5]
[5.5 5.  4.5 4.  3.5 3.  2.5 2.  1.5 1.  0.5 0. ]

print(array.shape)

(12,)

print(array[None,0:, None].ndim, array[None,0:, None].shape)
array[None,0:, None]

3 (1, 12, 1)





array([[[0. ],
        [0.5],
        [1. ],
        [1.5],
        [2. ],
        [2.5],
        [3. ],
        [3.5],
        [4. ],
        [4.5],
        [5. ],
        [5.5]]])

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

т.е. вместо matrix[i][j] нужно использовать matrix[i, j]

Массив, подставленный вместо индекса, может быть и списком номеров, и булевой маской:

array[[0, 2, 4, 6, 8, 10]]

array([0., 1., 2., 3., 4., 5.])

array[[True, False, True, False, True, False, True, False, True, False, True, False]]

array([0., 1., 2., 3., 4., 5.])

# Что будет выведено?
x = np.array([[1, 2, 3]])
y = np.array([1, 2, 3])

print (x.shape, y.shape)

print(np.array_equal(x, y))
print(np.array_equal(x, y[None, :]))

(1, 3) (3,)
False
True

x = np.arange(10)
x

array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

x[(x % 2 == 0) & (x > 5)]

array([6, 8])

print(x)
y = x[x>5] 
y *= 2
print(y)
print(x)

[0 1 2 3 4 5 6 7 8 9]
[12 14 16 18]
[0 1 2 3 4 5 6 7 8 9]

Срез массива в NumPy является представлением тех же данных, а не их копией: изменение среза наподобие x[2:5] приводит к изменению исходного массива. Отбор по маске или по списку индексов всегда возвращает копию, и исходный массив остаётся нетронутым. Когда требуются собственные данные, применяется метод copy.

x.copy()

array([0, 1, 2, 3, 4, 5, 6, 7, 8, 9])

Сохранение и чтение массивов в бинарном формате

with open('out.npy', 'wb') as f:
    np.save(f, x)
    
with open('out.npy', 'rb') as f:
    print(f.read())
    
with open('out.npy', 'rb') as f:
    y = np.load(f)
    print(y)    

b"\x93NUMPY\x01\x00v\x00{'descr': '<i8', 'fortran_order': False, 'shape': (10,), }                                                           \n\x00\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00\x00\x00\x00\x02\x00\x00\x00\x00\x00\x00\x00\x03\x00\x00\x00\x00\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00\x00\x05\x00\x00\x00\x00\x00\x00\x00\x06\x00\x00\x00\x00\x00\x00\x00\x07\x00\x00\x00\x00\x00\x00\x00\x08\x00\x00\x00\x00\x00\x00\x00\t\x00\x00\x00\x00\x00\x00\x00"
[0 1 2 3 4 5 6 7 8 9]

Чтение данных с помощью функции genfromtxt

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

sepal_length_in_cm, sepal_width_in_cm, petal_length_in_cm, petal_width_in_cm, class
1.0, 1.0, 10.0, 121.0, setosa
1.0, 314.0, 13.0, 121.0, versicolor

Если требуется работать с настоящими ирисами, их предоставляет scikit-learn одной строкой: from sklearn.datasets import load_iris.

iris = np.genfromtxt('iris_subset.txt', delimiter=', ', names=True, dtype=[('sepal_length_in_cm', 'f8'), 
                                                                          ('sepal_width_in_cm', 'f8'), 
                                                                          ('petal_length_in_cm', 'f8'), 
                                                                          ('petal_width_in_cm', 'f8'),
                                                                          ('class', 'U10')])
iris

array([(1.000e+00,   1. ,   10.,   121. , 'setosa'),
       (1.000e+00, 314. ,   13.,   121. , 'versicolor'),
       (1.134e+03,   1. ,  103.,  1421. , 'setosa'),
       (1.000e+00, 141. ,   10.,   121. , 'versicolor'),
       (1.440e+02,   1. , 4582., 13481. , 'versicolor'),
       (1.000e+00,  13.3,   10.,   121. , 'versicolor'),
       (1.141e+03,   1. , 1341.,  1231.1, 'setosa'),
       (7.320e+02, 131. ,  139.,    92.1, 'setosa')],
      dtype=[('sepal_length_in_cm', '<f8'), ('sepal_width_in_cm', '<f8'), ('petal_length_in_cm', '<f8'), ('petal_width_in_cm', '<f8'), ('class', '<U10')])

genfromtxt с names=True возвращает структурированный массив, хранящий имена столбцов вместе с данными. Строка из него запрашивается по номеру, а столбец — по названию.

print('Описание первого элемента: %s'%iris[0])
print('Значения столбца sepal_length_in_cm: %s'%iris['sepal_length_in_cm'])

Описание первого элемента: (1., 1., 10., 121., 'setosa')
Значения столбца sepal_length_in_cm: [1.000e+00 1.000e+00 1.134e+03 1.000e+00 1.440e+02 1.000e+00 1.141e+03
 7.320e+02]

sepal_length_setosa = iris['sepal_length_in_cm'][iris['class'] == 'setosa']
sepal_length_versicolor = iris['sepal_length_in_cm'][iris['class'] == 'versicolor']

print('Значения столбца sepal_length_in_cm\n\tclass setosa: %s\n\tclass versicolor: %s'%(sepal_length_setosa, 
                                                                                         sepal_length_versicolor))

Значения столбца sepal_length_in_cm
	class setosa: [1.000e+00 1.134e+03 1.141e+03 7.320e+02]
	class versicolor: [  1.   1. 144.   1.]

Строки в начале и в конце файла пропускаются аргументами skip_header и skip_footer, а столбцы отбираются через usecols.

iris_class = np.genfromtxt('iris_subset.txt', delimiter=', ', skip_header=1, usecols=4, dtype='U10')
iris_class

array(['setosa', 'versicolor', 'setosa', 'versicolor', 'versicolor',
       'versicolor', 'setosa', 'setosa'], dtype='<U10')

iris_features = np.genfromtxt('iris_subset.txt', delimiter=', ', skip_header=1, usecols=range(4))
iris_features

array([[1.0000e+00, 1.0000e+00, 1.0000e+01, 1.2100e+02],
       [1.0000e+00, 3.1400e+02, 1.3000e+01, 1.2100e+02],
       [1.1340e+03, 1.0000e+00, 1.0300e+02, 1.4210e+03],
       [1.0000e+00, 1.4100e+02, 1.0000e+01, 1.2100e+02],
       [1.4400e+02, 1.0000e+00, 4.5820e+03, 1.3481e+04],
       [1.0000e+00, 1.3300e+01, 1.0000e+01, 1.2100e+02],
       [1.1410e+03, 1.0000e+00, 1.3410e+03, 1.2311e+03],
       [7.3200e+02, 1.3100e+02, 1.3900e+02, 9.2100e+01]])

features_setosa = iris_features[iris_class == 'setosa']
features_versicolor = iris_features[iris_class == 'versicolor']

Операции в NumPy производятся над векторами одинаковой размерности целиком, без цикла.

Поэлементная разность двух векторов:

sepal_length_versicolor - sepal_length_setosa

array([    0., -1133.,  -997.,  -731.])

Аналогично для многомерных массивов.

features_versicolor - features_setosa

array([[ 0.00000e+00,  3.13000e+02,  3.00000e+00,  0.00000e+00],
       [-1.13300e+03,  1.40000e+02, -9.30000e+01, -1.30000e+03],
       [-9.97000e+02,  0.00000e+00,  3.24100e+03,  1.22499e+04],
       [-7.31000e+02, -1.17700e+02, -1.29000e+02,  2.89000e+01]])

Broadcasting

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

2*np.arange(1, 4)

array([2, 4, 6])

Правило согласования размерностей:

In order to broadcast, the size of the trailing axes for both arrays in an operation must either be the same size or one of them must be one.

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

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

a = np.ones((2, 3, 4))
b = np.ones(4)
c = a * b  # здесь a.shape = (2, 3, 4), а b.shape считается равным (1, 1, 4)

Прибавим к каждой строке матрицы один и тот же вектор:

np.array([[0, 0, 0], [10, 10, 10], [20, 20, 20], [30, 30, 30]]) + np.arange(3)

array([[ 0,  1,  2],
       [10, 11, 12],
       [20, 21, 22],
       [30, 31, 32]])

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

Сначала вектор, дополненный новой осью, приводится к виду:

np.arange(4)[:, np.newaxis]

array([[0],
       [1],
       [2],
       [3]])

Затем к нему прибавляется матрица:

np.arange(4)[:, np.newaxis]+np.array([[0, 0, 0], [10, 10, 10], [20, 20, 20], [30, 30, 30]])

array([[ 0,  0,  0],
       [11, 11, 11],
       [22, 22, 22],
       [33, 33, 33]])

Кроме того, в NumPy имеются сводные операции над массивами: np.min, np.max, np.sum, np.mean и т.д.

print('Среднее значение всех значений класса versicolor: %s'%np.mean(features_versicolor))
print('Среднее значение каждого признака класса versicolor: %s'%np.mean(features_versicolor, axis=0))

Среднее значение всех значений класса versicolor: 1192.20625
Среднее значение каждого признака класса versicolor: [  36.75   117.325 1153.75  3461.   ]

Вычислим без цикла \(\frac{1}{n} \sum\limits_{i=1}^n |x_i-y_i|\) для каждой пары \((x, y)\), где \(x\) обозначает вектор признаков объекта из класса setosa, а \(y\) вектор признаков объекта из класса versicolor.

np.mean(np.abs(features_setosa - features_versicolor[:, np.newaxis]), axis=2)

array([[7.900000e+01, 7.090000e+02, 9.727750e+02, 2.672250e+02],
       [3.500000e+01, 6.665000e+02, 9.302750e+02, 2.247250e+02],
       [4.518750e+03, 4.382250e+03, 4.121975e+03, 4.637475e+03],
       [3.075000e+00, 6.345750e+02, 8.983500e+02, 2.516500e+02]])

Операции

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

x = np.arange(40).reshape(5, 2, 4)
print(x)

[[[ 0  1  2  3]
  [ 4  5  6  7]]

 [[ 8  9 10 11]
  [12 13 14 15]]

 [[16 17 18 19]
  [20 21 22 23]]

 [[24 25 26 27]
  [28 29 30 31]]

 [[32 33 34 35]
  [36 37 38 39]]]

print(x.mean())
print(np.mean(x))

19.5
19.5

x.mean(axis=0)

array([[16., 17., 18., 19.],
       [20., 21., 22., 23.]])

x.mean(axis=1)

array([[ 2.,  3.,  4.,  5.],
       [10., 11., 12., 13.],
       [18., 19., 20., 21.],
       [26., 27., 28., 29.],
       [34., 35., 36., 37.]])

x.mean(axis=2)

array([[ 1.5,  5.5],
       [ 9.5, 13.5],
       [17.5, 21.5],
       [25.5, 29.5],
       [33.5, 37.5]])

x.mean(axis=(0,2))

array([17.5, 21.5])

x.mean(axis=(0,1,2))

19.5

Конкатенация многомерных массивов

Объединение массивов выполняют функции np.concatenate, np.hstack, np.vstack, np.dstack, различающиеся только осью объединения.

x = np.arange(10).reshape(5, 2)
y = np.arange(100, 120).reshape(5, 4)

x

array([[0, 1],
       [2, 3],
       [4, 5],
       [6, 7],
       [8, 9]])

y

array([[100, 101, 102, 103],
       [104, 105, 106, 107],
       [108, 109, 110, 111],
       [112, 113, 114, 115],
       [116, 117, 118, 119]])

np.hstack((x, y))

array([[  0,   1, 100, 101, 102, 103],
       [  2,   3, 104, 105, 106, 107],
       [  4,   5, 108, 109, 110, 111],
       [  6,   7, 112, 113, 114, 115],
       [  8,   9, 116, 117, 118, 119]])

x = np.ones([2, 3])
y = np.zeros([2, 2])

# Какой будет результат
print(np.hstack((x,y)).shape)
print(np.vstack((x,y)).shape)

(2, 5)



---------------------------------------------------------------------------

ValueError                                Traceback (most recent call last)

Cell In[54], line 3
      1 # Какой будет результат
      2 print(np.hstack((x,y)).shape)
----> 3 print(np.vstack((x,y)).shape)


File /opt/anaconda3/lib/python3.12/site-packages/numpy/core/shape_base.py:289, in vstack(tup, dtype, casting)
    287 if not isinstance(arrs, list):
    288     arrs = [arrs]
--> 289 return _nx.concatenate(arrs, 0, dtype=dtype, casting=casting)


ValueError: all the input array dimensions except for the concatenation axis must match exactly, but along dimension 1, the array at index 0 has size 3 and the array at index 1 has size 2

p = np.arange(1).reshape([1, 1, 1, 1])
p

array([[[[0]]]])

print("vstack: ", np.vstack((p, p)).shape)
print("hstack: ", np.hstack((p, p)).shape)
print("dstack: ", np.dstack((p, p)).shape)
print("concatenate: ", np.concatenate((p, p), axis=3).shape)

vstack:  (2, 1, 1, 1)
hstack:  (1, 2, 1, 1)
dstack:  (1, 1, 2, 1)
concatenate:  (1, 1, 1, 2)

Типы

От типа массива зависят и занимаемая память, и диапазон представимых значений. Рассмотрим, что происходит с числом 70000 в uint16. С версии NumPy 2.0 конструктор массива на таком значении завершается ошибкой OverflowError, а без предупреждения оно усекается только при явном приведении через astype, превращаясь в 4464; такое переполнение, не сопровождаемое ошибкой, является классическим источником неверных результатов.

x = [1, 2, 70000]

np.array(x, dtype=np.float32)

array([1.e+00, 2.e+00, 7.e+04], dtype=float32)

np.array(x, dtype=np.uint16)

OverflowError: Python integer 70000 out of bounds for uint16

Ранее NumPy усекал значение, не помещавшееся в тип, и лишь выдавал предупреждение; с версии 2.0 это ошибка. Незаметное переполнение осталось только при явном приведении:

np.array(70000).astype(np.uint16)

4464

uint16 хранит остаток по модулю \( 2^{16} \), а \( 70000 - 65536 = 4464 \). Такая ошибка не приводит к исключению и ничего не выводит.

np.array(x, dtype=np.str_)

array(['1', '2', '70000'], dtype='<U5')

Функциональное программирование

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

def f(value):
    return np.sqrt(value)

print(np.apply_along_axis(f, 0, np.arange(10)))

[0.         1.         1.41421356 1.73205081 2.         2.23606798
 2.44948974 2.64575131 2.82842712 3.        ]

vf = np.vectorize(f)

%%timeit 
vf(np.arange(100000))

146 ms ± 2.4 ms per loop (mean ± std. dev. of 7 runs, 10 loops each)

%%timeit 
np.apply_along_axis(f, 0, np.arange(100000)) 

1.89 ms ± 31.9 μs per loop (mean ± std. dev. of 7 runs, 1,000 loops each)

%%timeit 
np.array([f(v) for v in np.arange(100000)])

129 ms ± 861 μs per loop (mean ± std. dev. of 7 runs, 10 loops each)

Разница в семьдесят раз выглядит убедительно, однако выводы из неё были бы поспешными. np.vectorize и списковое включение вызывают f сто тысяч раз, и 130–150 миллисекунд составляют стоимость ста тысяч вызовов функции Python. В то же время apply_along_axis с axis=0 на одномерном массиве вызывает f один раз, передавая в неё весь массив целиком, так что измерен здесь один векторный np.sqrt, а не поэлементный обход.

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