На пути к ядру Питона

Привет! Представляю вашему вниманию перевод статьи Toward a “Kernel Python” ^[1] автора Glyph Lefkowitz (создателя фреймворка Twisted).

Подробнее — под катом.

Магия минимализации стандартной библиотеки

Под влиянием выступления Эмбер Браун ^[2] прошлым месяцем на Python Language-саммите (имеется в виду ее майский доклад «Батарейки включены, но они протекают» — прим. переводчика) Кристиан Хаймс продолжил свою работу ^[3] по уменьшению стандартной питоновской библиотеки и создал предложение PEP 594 ^[4] для удаления явно устаревших и неподдерживаемых ее фрагментов.

Появление PEP 594 («Удаление мертвых батареек из стандартной библиотеки») — это отличная новость для питонистов, особенно для тех, кто поддерживает стандартную библиотеку и теперь будет иметь меньший фронт работ. Краткая экскурсия по PEP-галерее устаревших или требующих удаления модулей говорит сама за себя (модули sunau, xdrlib, и chunk — мои личные фавориты). Стандартная питоновская библиотека содержит множество полезных модулей, однако, она также включает настоящий некрополь кода, возвышающийся памятник морально устаревших обломков, грозящих в любой момент похоронить своих разработчиков.

Тем не менее, я считаю, что в данном PEP-предложении может быть воплощен ошибочный подход. В настоящее время стандартная библиотека поддерживается в тандеме с разработчиками CPython. Большие ее куски оставлены в смутной надежде, что это когда-нибудь кому-нибудь принесет пользу. В вышеупомянутом PEP этот принцип можно пронаблюдать при защите модуля colorsys. Почему бы не удалить его? Ответ: «Этот модуль нужен для преобразования CSS-цветов между системами координат (RGB, YIQ, HSL и HSV). [Он] не накладывает дополнительных расходов на основную разработку».

Были времена, когда доступ в Интернет был ограничен, и, возможно, это была хорошая идея предварительно загрузить Python со всей кучей материала, однако в наше время модули, необходимые для преобразования цветов между различными системами координат, находятся в одном шаге от команды pip install.

Почему вы не рассмотрели мой пул-реквест?

Итак, давайте рассмотрим это утверждение: накладывают ли крошечные модули вроде colorsys «дополнительные расходы на основную разработку»?

Главным разработчикам достаточно уже того, что они пытаются поддерживать огромную и древнюю базу кода на C, которая представляет собой сам CPython. Как сказала Мариэтта Виджия в своем выступлении ^[5] на North Bay Python, наиболее частым вопросом, который задается разработчикам ядра, является: «Почему вы еще не взглянули на мой пул-реквест?» И каков ответ? Проще игнорировать эти пул-реквесты. Вот что значит быть разработчиком ядра!

Можно было бы спросить, есть ли у Twisted такая же проблема? Twisted — это тоже большая коллекция слабо связанных модулей; своего рода стандартная библиотека для сетей. Являются ли все эти клиенты и сервера для SSH, IMAP, HTTP, TLS и т.д. и т.п. попыткой втиснуть всё в один пакет?

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

В идеале в какой-то момент каждый подпроект в Twisted должен стать отдельным проектом со своим собственным репозиторием, непрерывной интеграцией (CI), веб-сайтом и, конечно же, со своими собственными более сфокусированными разработчиками. Мы уже медленно, но верно делим проекты, где можно провести естественную границу. Некоторые моменты, которые начались в Twisted как constantly и incremental, разделены, deferred и filepath — в процессе разделения. Другие проекты, такие как klein и treq, продолжают жить отдельно. Мы сделаем больше, когда мы выясним, как уменьшить затраты на настройку и поддержку непрерывной интеграции и как выпустить инфраструктуру для каждого из них.

Но является ли монолитная природа Twisted самой актуальной или даже серьезной проблемой для проекта? Давайте оценим это.

На момент написания этой статьи у Twisted было в очереди 5 нерешенных нерассмотренных пул-реквестов. Среднее время, которое тратится на рассмотрение тикета, составляет, грубо говоря, четыре с половиной дня. Самый старый тикет в очереди датируется 22 апреля, что означает, что прошло менее 2 месяцев с тех пор, как был отправлен самый старый нерассмотренный пул-реквест.

Всегда сложно найти достаточное количество разработчиков и времени, чтобы отвечать на пул-реквесты. Иногда кажется, что мы всё еще получаем слишком часто вопрос «Почему вы не рассматриваете мой пул-реквест?». Мы не всегда делаем это идеально, но в целом справляемся; очередь колеблется между 0 и 25 или около того в самом неудачном месяце.

А как обстоят дела у ядра CPython, по сравнению с этими цифрами?

Зайдя на гитхаб ^[6], можно увидеть, что в данный момент рассмотрения ждут 429 тикетов. Самый старый из них ожидает со 2 февраля 2018 года, то есть почти 500 дней.

Сколько проблем с интерпретатором и сколько проблем с библиотекой stdlib? Очевидно, что задержка с рассмотрением — это проблема, но поможет ли удаление stdlib?

Для быстрой и ненаучной оценки я просмотрел первую (самую старую) страницу пул-реквестов. По моей субъективной оценке, из 25 пул-реквестов 14 были связаны со стандартной библиотекой, 10 — с ядром языка или кодом интерпретатора и один связан с небольшой проблемой с документацией. Рискну предположить на основе этой пропорции, что где-то около половины нерассмотренных пул-реквестов связаны со стандартным библиотечным кодом.

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

Факт, что ни один из открытых пул-реквестов CPython не связан с модулем colorsys. Действительно он не накладывает затрат на разработку ядра. Разработка ядра сама налагает эти затраты. Если бы я хотел обновить модуль colorsys, чтобы шагать в ногу со временем (возможно, иметь объект Color, возможно, для поддержки целочисленных цветовых моделей), скорее всего, мне пришлось бы ждать 500 дней или больше.

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

Новые окружения, новые требования

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

Подкаст ^[7] за подкастом ^[8], подкаст ^[9] за докладом ^[10] говорят нам, что для продолжения успеха и развития Python-у нужно расти в новых областях: особенно в веб-фронтенде, а также мобильных клиентах, встроенных системах и консольных играх.

Эти окружения требуют выполнения одного или двух условий:

• совершенно другую среду выполнения (см. Brython ^[11] или MicroPython ^[12])
• модифицированную урезанную версию стандартной библиотеки.

Во всех этих случаях камнем преткновения является определение модулей, которые необходимо удалить из стандартной библиотеки. Их нужно найти методом проб и ошибок; прежде всего, процесс полностью отличается от стандартного процесса определения зависимостей в приложении Python. Не существует объявления install_requires в setup.py, сообщающего, что в библиотеке используется модуль из stdlib, который целевая среда выполнения Python может пропустить из-за ограниченности объема.

Проблема может возникнуть, даже если всё, что мы используем, является стандартным Питоном на Linux-установке. Даже дистрибутивы Linux для серверов и настольных компьютеров испытывают равную потребность в меньшем пакете ядра Python, поэтому в них уже довольно произвольно урезана стандартная библиотека. Это может не соответствовать требованиям питоновского кода и в результате привести к ошибкам, когда даже pip install не будет работать ^[13].

Уберите всё это

«А как насчет предположения о том, что нужно убирать понемногу каждый день? Хотя оно звучит убедительно, не позволяйте себя обмануть. Причина, по которой вам кажется, что уборка никогда не заканчивается, заключается именно в том, что вы убираете понемногу. [...] Главный секрет успеха таков: если убирать одним махом, а не постепенно, то можно навсегда изменить свое мышление ^[14] и жизненные привычки»

Мари Кондо, «Магическая уборка. Японское искусство наведения порядка дома и в жизни» (стр. 15-16)

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

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

В некоторых бизнес-средах идея с огромной стандартной библиотекой кажется привлекательной из-за того, что добавление зависимостей в requirements.txt бюрократизируется, однако, «стандартная библиотека» в таких средах имеет чисто произвольные границы.

Неплохой идеей может быть по-прежнему поставлять часть бинарных дистрибутивов CPython (возможно, даже официальных) с широким выбором модулей из PyPI. Ведь даже для обычных задач требуется определенный объем библиотеки stdlib, необходимый pip-у, чтобы установить другие нужные модули.

Сейчас сложилась такая ситуация, когда pip распространяется вместе с Python, но в репозитории CPython не разрабатывается. Часть того, с чем поставляется дефолтный установщик Python, разработано в репозитории CPython, часть идет в отдельном исходном архиве (tarball) для интерпретатора.

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

Заключение

Философия «Батарейки включены» идеально подходила для времени своего создания; подобно ракете-носителю, она доставила Python программирующей публике. Однако по мере созревания экосистем опен-сорса и пакетов Python эта стратегия устарела, и, как и любому ускорителю, мы должны дать ей вернуться на землю, чтобы она не утащила нас назад.

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

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

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

А теперь: кто желает написать PEP ^[15]?

Автор: YernarShambayev

Источник ^[16]