Вместо предисловия
Вряд ли найдётся питонист, который не знает об import this. Наберите эту инструкцию в интерпретаторе и увидите "Дзен Python", 19 афоризмов Тима Питерса о том, каким должен быть хороший код. Их цитируют в докладах, вешают на стены, используют как аргумент в спорах о стиле. Это, пожалуй, самая известная пасхалка во всём Python.
Но история этой пасхалки известна куда меньше. Осенью 2001 года оргкомитет десятой международной конференции по Python объявил конкурс на слоган для футболки. Пришло около пятисот заявок, почти все ужасные. Тим Питерс, просмотрев их, написал коллегам: "Боже, я не могу смотреть на это больше пяти минут, мозг превращается в кашу". В итоге выбор финального слогана выпал на двух человек, которые были "достаточно безумны, чтобы ещё заботиться об этом". Одним из них был Барри Уорсо (Barry Warsaw). Именно он выбрал import this из двух финалистов. И именно он тут же предложил: а давайте реализуем это как модуль и тихо добавим в Python 2.2, зашифровав в rot13, чтобы пасхалка не раскрывалась при беглом просмотре исходника.
По словам Барри, прошло немало времени, прежде чем кто-то её нашёл... Об этом удивительном человеке и пойдет речь.
Школьник на заре open source
Барри начал программировать, будучи старшеклассником. Он писал код в исследовательской лаборатории при правительстве США. Лаборатория была подключена к ARPANET, предшественнику современного интернета, и к Usenet, тогдашнему аналогу форумов, где разработчики со всего мира обменивались кодом, патчами и идеями.
Поскольку лаборатория финансировалась из кармана налогоплательщиков, весь написанный там код автоматически становился общественным достоянием: его можно было свободно раздавать, получать улучшения в ответ, сотрудничать с незнакомыми людьми на другом конце планеты.
Позже Барри напишет
Это было свободное программное обеспечение с открытым исходным кодом ещё до того, как такие понятия вошли в обиход.
Первый неголландец в Python
Python родился в Нидерландах. В конце 1989 года Гвидо ван Россум начал работу над новым языком в амстердамском исследовательском институте CWI. Первые соратники и контрибьюторы, Схерд Мюлендер и Джек Янсен, были коллегами Гвидо. Так сложилось, что первые годы Python оставался проектом сугубо голландских программистов.
Всё изменилось летом 1994 года. Барри вошёл в core team CPython, став четвёртым по старшинству разработчиком в истории языка и первым неголландцем.
Я понятия не имел, насколько это изменит мою жизнь – и в личном, и в профессиональном плане
В это же время в сообществе разгорелась дискуссия с говорящим названием "If Guido was hit by a bus?", что будет с языком, если с его создателем что-то случится? Дискуссия привела к тому, что Гвидо получил приглашение провести 2 месяца в американском институте стандартов и технологий NIST в Мэриленде. Там, в ноябре 1994 года, состоялся первый в истории воркшоп по Python, на котором собралось около 20 человек, половина из которых сформировала костяк тех, кто продолжил развивать язык.
Гвидо позднее вспоминал:
Из примерно двадцати участников около половины до сих пор активно участвуют в сообществе Python, а некоторые сами стали крупными лидерами проектов с открытым исходным кодом – Джим Фултон из Zope и Барри Уорсо из GNU Mailman.
Рождение PEP
После воркшопа 1994 года Барри оказался в самом центре Python-разработки. Он работал вместе с Гвидо в команде под неофициальным названием Pythonlabs. Сначала команда работала в CNRI (Корпорация национальных исследовательских инициатив), затем в Zope Corporation. Именно в этот период Барри придумал и оформил одну из самых важных вещей в истории Python — стандарт, который определяет, как Python развивается: как предлагаются новые идеи, как они обсуждаются и как принимаются решения.
Конечно же, речь о "предложениях по улучшению Python" (Python Enhancement Proposal, PEP). Именно Барри придумал саму аббревиатуру, смоделировал процесс по образцу RFC (стандарты интернет-сообщества) и вместе с коллегами описал этот процесс в PEP 1.
Мы намерены сделать PEP основным механизмом для предложения крупных новых функций, сбора мнений сообщества и документирования решений, принятых при разработке Python.
Барри также ввёл роль BDFL-Delegate – механизм, позволявший Гвидо делегировать финальное решение по конкретному PEP эксперту.
В этот же период Барри стал одним из основателей PSF (Python Software Foundation), организации, которая по сей день управл��ет развитием языка.
За годы работы Барри стал автором или соавтором 37 PEP.
Mailman: половина мировых рассылок
Первую версию известного open source менеджера почтовых рассылок GNU Mailman написал студент-аспирант Джон Вьега в начале 90-х, чтобы связать фанатов с группой Dave Matthews Band, с участниками которой он дружил в колледже. До появления Mailman стандартом де-факто в Unix/Linux мире был Majordomo, менеджер рассылок на Perl. Именно на нём держались рассылки Python-сообщества. Но у Majordomo была принципиальная проблема: его архитектура была настолько негибкой, что добавить даже минимальную защиту от спама превращалось в мучение.
Барри вспоминал с иронией:
Для мира Python было бы просто недопустимо поддерживать столько Perl-кода.
Исходники первой версии Mailman Вьега потерял из-за сбоя жёсткого диска. Проект подхватил Кен Манхаймер из CNRI, того самого института, где в то время работали Гвидо и Барри. Когда Манхаймер ушёл из института, проект перешёл к Барри и с тех пор, с конца 90-х, он стал его ведущим разработчиком.
На протяжении десятилетий Mailman стал фактически стандартом для open source сообществ: на нём работали рассылки самого Python, Ubuntu, тысяч других проектов.
В 2008 году, представляя Барри перед интервью, о Mailman написали:
Mailman, вероятно, обслуживает около половины всех почтовых рассылок в мире
Сегодня Mailman 3 входит во всех основных Linux-дистрибутивах и продолжает активно поддерживаться. Барри по-прежнему числится среди ведущих разработчиков проекта.
Барри на удаленке: Линукс как работа, Python и музыка как у��овольствие
В 2007 году Барри присоединился к Canonical (компания-разработчик Ubuntu, дистрибутив Линукс).
Друзья и родственники часто спрашивают меня, чем я занимаюсь на работе. Когда мой брат говорит, что он бухгалтер, это легко понять. Но объяснить сложный мир разработки программного обеспечения с открытым исходным кодом, в котором я живу, куда труднее. Иногда я говорю примерно следующее: ну, ты знаешь, что такое Windows, и знаешь, что такое Mac, правда? Мы создаём третью альтернативу под названием Ubuntu – бесплатную, основанную на Linux и в большинстве случаев значительно лучшую. Упомяни, что вирусов не будет и что она легко вдохнёт новую жизнь в тот старый тормозящий компьютер, к которому страшно подходить, и люди понимающе кивают, даже если не вполне понимают суть. Источник
В интервью 2008 года он описывал свой рабочий день так:
Canonical – почти полностью виртуальная компания; большинство из нас работают из дома и встречаются лично лишь пару раз в год. У удалённой работы есть свои плюсы и минусы, она подходит не всем, но я её обожаю. Мой кабинет в спальне на втором этаже, и одно из главных удовольствий – открывать окна в хорошую погоду. Плюс возвращаешь себе два часа жизни в день, которые иначе провёл бы в пробках на вашингтонской кольцевой! У меня же единственная проблема с движением возникает, когда приходится обходить собаку.
В том же интервью есть фотография его рабочего стола:
Мой письменный стол (в отличие от "рабочего стола" на экране) служит двум целям. Здесь я пишу код и для работы (как сотрудник Canonical), и для удовольствия, работая над Python, Mailman и другими проектами с открытым исходным кодом. Но я ещё и музыкант-любитель: бас-гитара – мой основной инструмент, последние несколько лет я всё глубже погружаюсь в мир цифровых аудиостанций (DAW).
Вот моя типичная рабочая обстановка. Разумеется, её безупречный вид не постановочный. Два монитора в центре подключены через KVM к моему трёхлетнему десктопу Dell с Ubuntu 8.10 (Intrepid) – это основная рабочая машина. Я твёрдо убеждён: "много экранного пространства не бывает", поэтому слева виден IBM ThinkPad X40 (с его дефектным воющим блоком питания) тоже на Intrepid. Справа MacBook Pro, в данный момент на OS X 10.5 (Leopard). Центральные мониторы, клавиатура и трекбол переключаются также на Mac с двумя процессорами G5 по 2,7 ГГц – тоже Leopard.
С особым удовольствием (и неизменной иронией) Барри рассказал о клавиатуре
Как видно на фото, я использую клавиатуру Microsoft Natural – пожалуй, единственный продукт Microsoft в моём доме. Честно говоря, эта клавиатура спасла мою карьеру: прямые клавиатуры для меня – орудия пытки, которым место разве что на столах в Гуантанамо.
На другой фотографии видна коллекция гитар по соседству с компьютерами
Итак: гитара, пара бас-гитар, джембе и спутанная масса патч-кордов, педалей, наушников и аудиоинтерфейсов. Всем этим я пользуюсь постоянно: пишу музыку или работаю над песнями для одной из своих групп.
Менеджер релиза Python 3.0
Переход Python-сообщества на Python 3 был одним из самых болезненных процессов в истории языка: разрыв обратной совместимости, годы параллельной поддержки двух веток, бесконечные споры. Барри в буквальном смысле оказался центре этого процесса. Именно он был менеджером релиза Python 3.0.
2 декабря 2008 года Барри в рассылке python-committers объявил о заморозке кодовой базы перед релизом, сделав лишь одно маленькое исключение для самого Гвидо. Ему в период релиза Барри разрешил только править раздел "Что нового в Python".
3 декабря 2008 года Барри напишет:
Я создал тег final для 3.0 и приступаю к формированию архива с исходным кодом. Планирую сделать их доступными для проверки перед объявлением релиза.
Это письмо фиксирует момент, когда Python 3.0 появился на свет.
Ветка py3k теперь открыта для Python 3.1! Удачи, увидимся через 18 месяцев.
Но выпуск Python 3.0 был лишь началом, теперь нужно было пересадить сообщество на новую версию.
PEP 404, или Python 2.8, которого не будет никогда
В 2011 году вопрос "будет ли Python 2.8?" был вполне актуальным. Часть сообщества надеялась на выход этой версии как на способ получить новые возможности, не переходя на Python 3, который разрывал обратную совместимость. Вопрос висел в воздухе, на него нужно было ответить ясно, официально и окончательно.
Барри ответил, подготовив, пожалуй, самый остроумный документ в истории Python: PEP 404 "Python 2.8 Un-release Schedule".
Внешне это обычный PEP: заголовок, метаданные, обоснование, расписание релиза. Вот только расписание выглядит так:
дата финального релиза – "Never"
менеджер релиза – "Cardinal Biggles" (персонаж Монти Пайтона из скетча про испанскую инквизицию, чье главное оружие фанатичная преданность Папе)
Ирония иронией, но далее Барри объясняет причину такого решения
Поскольку поддержка нескольких версий Python существенно истощает ресурсы разработчиков, а улучшения языка и библиотек, воплощённые в Python 3, слишком важны, было принято решение завершить линейку Python 2 на версии 2.7. Таким образом, всё новое развитие происходит в ветке Python 3, и официального релиза Python 2.8 не будет никогда. Python 2.7, однако, будет поддерживаться дольше обычного.
Python 2.7 действительно поддерживался дольше обычного, значительно дольше. Официальное завершение поддержки состоялось лишь 1 января 2020 года, почти через девять лет после выхода PEP 404. Всё это время сообщество методично мигрировало и Барри был одним из тех, кто этот процесс подталкивал.
Отец __pycache__
Сосуществование нескольких версий Python в одном дистрибутиве было настоящей головной болью. Когда Python компилировал foo.py, он сохранял результат в foo.pyc прямо рядом с исходником. Если в системе были установлены Python 2.6 и Python 3.1 одновременно, обе версии претендовали на один и тот же файл и перезаписывали его по очереди.
Барри решил эту проблему в PEP 3147 (2009). Была введена всем известная директория __pycache__, куда Python теперь складывает скомпилированные файлы с тегом версии в имени: foo.cpython-32.pyc, foo.cpython-33.pyc и т.д. Любое количество версий Python могут мирно соседствовать. PEP 3149 (2010), также под авторством Барри, решил ту же проблему для скомпилированных C-расширений (файлов .so).
Python в Линукс: стратегия на годы вперёд
Барри не просто писал код для Ubuntu, но и отчасти определял стратегию развития дистрибутива. В 2011 году он дважды съездил на Ubuntu Developer Summit. Это были регулярные встречи, где определялось, каким будет следующий Ubuntu. Барри приезжал туда с конкретной повесткой: что делать с Python в Ubuntu.
Суть стратегии была проста: не ждать, пока сообщество само перейдёт на Python 3, а мягко подталкивать его через дистрибутивы операционной системы. Ubuntu – один из самых популярных Linux-дистрибутивов с миллионами пользователей. Если Ubuntu последовательно убирает старые версии Python и перестаёт поставлять Python 2 по умолчанию – это сигнал для всей экосистемы. Разработчики пакетов вынуждены портировать свой код, а вслед за ними подтягиваются и все остальные.
Моё долгосрочное видение: Ubuntu 14.04 не будет иметь Python 2 на установочных образах вообще. Источник
Но вот с реализацией было не всё гладко.
Первая проблема – внешняя. Ubuntu исторически опирался на Debian: большинство пакетов сначала появляются там, а потом синхронизируются в Ubuntu. Уходить слишком далеко вперёд Debian было рискованно, можно потерять синхронизацию. Барри вынужден был ждать, пока Debian завершит переход на Python 2.7 как версию по умолчанию.
Вторая проблема была внутри самой Canonical. Веб-платформа Launchpad (что-то вроде Гитхаба для экосистемы Ubuntu) не была портирована на Python 2.7. Причина простая: серверы Canonical работали на предыдущем LTS-релизе Ubuntu, где Python 2.7 попросту отсутствовал. Замкнутый круг: чтобы портировать Launchpad на новый Python, нужен новый Ubuntu, а новый Ubuntu требует, чтобы Launchpad уже был портирован. Барри решил это через отдельный репозиторий с бэкпортом Python 2.7 для старого LTS.
Долгосрочное видение Барри в итоге сбылось, но с опозданием. Python 2 исчез с установочных образов Ubuntu не в версии 14.04, а в 20.04 LTS, вышедшей в апреле 2020 года.
С Python навсегда
Из Canonical Барри перешел в LinkedIn, где занял позицию Senior Staff Engineer в команде Python Foundation. Работа та же: поддержка Python-инфраструктуры, переход на Python 3, только теперь в масштабах одной из крупнейших соцсетей мира. LinkedIn официально выделял ему 20% рабочего времени на open source.
Параллельно Барри 5 раз избирался в Steering Council, орган управления Python, появившийся в 2019 году после того, как Гвидо сложил с себя полномочия "великодушного пожизненного диктатора". Барри является действующим членом совета на момент написания статьи.
Вместо послесловия: ещё одна пасхалочка от Барри и его отношение к open source
>>> from __future__ import barry_as_FLUFL >>> 5 <> 4 True >>> 5 <> 5 False >>> 5 != 4 File "<stdin>", line 1 5 != 4 ^^ SyntaxError: with Barry as BDFL, use '<>' instead of '!=' >>>
Барри, Friendly Language Uncle For Life (FLUFL), вернул оператор <> из Python 2 :)
Подробности в PEP 401 2009 года.
Как писал Барри (правда, применительно к рождению Zen оf Python):
То были времена, когда у Python-сообщества было чувство юмора.
И напоследок хотелось бы привести слова Барри об open source
Для меня свободный и открытый софт гораздо больше чем просто код, который мы пишем. Это сотрудничество, сообщество, обучение, преподавание и по-настоящему позитивное влияние на мир. Это возможность дать людям раскрыть свой потенциал, построить репутацию на основе заслуг, найти свои области интересов и экспертизы и соотнести их с жизнью общества. Понимать, что твоё мнение и вклад имеют значение. Открытый исходный код – это смелость отстаивать свои убеждения, но и смирение признать то, что ты ошибаешься, или то, что у кого-то идея лучше твоей. Это активный поиск консенсуса и вместе с тем умение выстроить вдумчивый и сочувствующий процесс принятия трудных решений там, где консенсус недостижим. Это умение заражать энтузиазмом и вести за собой, а иногда, с радостью и смирением, принимать чужую точку зрения.
