Вопрос, который эта страница снимает: достаточно ли канона. Ответ — зависит от того, для чего. Канон отвечает на «почему язык такой»; он не отвечает на «как написать этот кусок кода красиво», не покрывает стандартную библиотеку и не заменяет опыта. Ниже — что стоит читать дальше, разложенное по тому, какой именно вопрос закрывает источник, а не по рейтингам.
Один принцип отбора. Приоритет у первоисточника. Документация и PEP’ы бесплатны, точны и написаны теми, кто принимал решения; почти любая статья о Python — это их пересказ с потерями. Книги нужны там, где первоисточник не даёт связности: он описывает что, а не в каком порядке это укладывать в голову.
1Первоисточники
Всё бесплатно, всё точно, и почти ничего из этого не читают целиком — а зря.
Единственный документ, который стоит прочитать целиком и не по диагонали. Это и есть спецификация объектной модели: что такое объект, какие у него есть слоты, что обязан делать каждый дандер. Всё, что в каноне помечено 🔒, взято отсюда. Читать после R1 и R4 — до них текст выглядит как перечень, после них как система.
Раймонд Хеттингер разбирает дескрипторы с чистыми Python-реализациями property, classmethod и staticmethod. Лучший из существующих текстов на эту тему, и он же самый короткий. Прямое продолжение главы 04.
Четыре страницы про области видимости, связывание имён и то, почему nonlocal вообще понадобился. Отвечает на половину вопросов, которые обычно задают про замыкания.
Официальное описание устройства интерпретатора: компилятор, объектная модель на уровне C, сборщик мусора. Написано для тех, кто собирается править CPython, поэтому без популяризаторских упрощений — и поэтому же местами тяжело. Читать выборочно, под конкретный вопрос.
Уникальное свойство PEP: там есть раздел «Rejected ideas» и мотивация. Ни в одной книге не написано,
почему решили именно так. Минимальный набор под этот канон:
393 строки,
412 разделяемые ключи,
442 финализация,
484 типы,
492 async/await,
525 асинхронные генераторы,
563 отложенные аннотации,
659 специализация,
703 free-threading.
Не «читать код», а читать комментарии в шапках файлов: они написаны как проектная документация.
dictobject.c объясняет компактную раскладку лучше любой статьи,
listobject.c — закон роста,
obmalloc.c — арены и пулы. По сорок строк каждый.
2Книги
Четыре штуки. Больше не нужно: остальные либо повторяют эти, либо учат синтаксису.
Ближайший родственник этого канона и лучшее дополнение к нему. Пересечение большое — объектная модель, протоколы, дескрипторы, корутины, — но угол другой: Рамальо идёт от того, как писать, канон от того, почему так устроено. Что есть у него и нет здесь: подробный разбор стандартной библиотеки, конкурентность на уровне рецептов, метапрограммирование как рабочий приём. Второе издание переписано под 3.10, первое (2015) устарело сильно — брать только второе.
Единственная книга, которая ведёт читателя по исходникам интерпретатора подряд: сборка из исходников, лексер, парсер, компилятор, цикл вычисления, объекты, память, GIL. Если после уровня L3 в главах хочется не отдельных мест, а сплошного прохода — это оно. Версия 3.9: специализация 3.11 и JIT 3.13 туда не попали, всё остальное актуально.
Язык без воды: Бизли выкинул всё, что можно посмотреть в документации, и оставил модель. Полезна как перекрёстная проверка — если после канона какая-то глава Distilled читается как очевидная, тема закрыта. Тонкая и быстрая.
Продолжение главы 21 в масштабе книги: профилирование, numpy, Cython, кластеры, поле «когда переписывать». Третье издание вышло в 2025-м и учитывает 3.11–3.13, что здесь принципиально — предыдущее издание давало советы, устаревшие вместе с версией.
3Доклады и статьи
То, что имеет смысл смотреть и читать целиком, а не по поиску.
Доклад, после которого о GIL стали говорить точно. Бизли на осциллограмме показывает, что при CPU-нагрузке два потока работают медленнее одного, и объясняет почему. Пятнадцать лет спустя механизм переключения другой, а разбор — по-прежнему лучший. Смотреть после главы 19.
Пятнадцать длинных статей о внутренностях CPython: цикл вычисления, объекты, атрибуты, GIL, импорт, async. По глубине между devguide и книгой Шоу, по подаче — лучше обоих. Бесплатно и с иллюстрациями.
LWN пишет о разработке CPython изнутри: что обсуждали на языковых саммитах, что не приняли и по каким причинам. Единственный способ увидеть аргументацию core-разработчиков без чтения рассылок.
Самое внятное объяснение copy-and-patch JIT и того, как он соотносится со специализацией из 3.11. Прямое продолжение главы 21.
4Чего читать не стоит
Не из снобизма, а потому, что это активно вредит — даёт ложное ощущение понимания.
- Подборки «N трюков Python». Каждый трюк — следствие какого-то механизма, вырванное из контекста. Выученный список трюков не позволяет вывести следующий, а понятый механизм позволяет.
- Статьи об оптимизации старше 3.11. Специализация переписала расклад: «list comprehension быстрее цикла» превратилось из 30% в 6%, «избегай точек в цикле» перестало работать вовсе. Дата публикации здесь важнее автора.
- Пересказы GIL без замеров. Их сотни, и большая часть повторяет одну и ту же ошибку: путает атомарность байткод-инструкции с корректностью операции. Проверять просто — если в тексте нет ни одного числа, полученного на машине автора, читать не надо.
- Готовые ответы на вопросы собеседований. Отдельно оговорено в принципах этого канона: заученный ответ ломается на первом уточняющем вопросе, выведенный — нет.
Как понять, что дальше читать не нужно. Простой тест: взять любое утверждение из реестра «гарантия или деталь» и объяснить, откуда оно берётся, не подглядывая. Если получается для большинства строк — дальше стоит не читать, а писать код и мерить. Канон закрывает вопрос «почему»; дальше вопросы становятся конкретными, и на них отвечает документация, а не следующая книга.