Очередная новость: Гугл пожертвует $350k на разработку Python.

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

Президентом фонда является Гвидо ван Россум, изначальный разработчик языка. Что ж, дело хорошее. Гвидо настоящий программист и знает своё дело (в отличие от Расмуса Ледорфа, разработчика PHP, который никогда способным программистом не был и за почти 30 лет разработки своего языка не потрудился хоть какой-то талант развить, и к программированию и программистам относится с демонстративным пренебрежением).

Одновременно, Гвидо работает в Microsoft, недавно выйдя из "официального ухода на пенсию". В 65 лет захотелось поработать фулл-тайм. Поработать не в своём фонде над своим языком, а в коммерческой компании.

Вот такой вот успешный язык.

Ну что ж, а куда пойдут деньги?

Посмотрим отчёт за предыдущий период (2019 год):
- по тысяче баксов каждому из сотни докладчиков международных конференций, на билеты и пиво ($140k)
- тудым, сюдым, проекты всякие, поддержка в Android ($250k)
- тудым, сюдым, организационные издержки, хостинги, всё такое ($50k)
- тудым, сюдым, тренинги всякие, "инициативы по всему миру" ($325k)
- тудым, сюдым, "усиление брендов", "торговые марки" ($270k)
- разработка python ($25k)

Ну то есть КПД фонда примерно 2.5% ($25k от $1M). Остальное ушло кому надо и на какие надо важные дела. При этом номинальный глава фонда вынужден в 65 лет снова выходить на работу.

Не трудно прикинуть, что даже если целиком годовое пожертвование Гугла направить на разработку Python, то его хватит на работу, в лучшем случае, двух хороших американских программистов.

По-моему это не поддержка, а насмешка какая-то.

#programming #python

Python software foundation: "фирма" работает

Немного взглянули в прошлый раз на бухгалтерию Python Software Foundation. Внешне организация маскируется под такое формальное легальное прикрытие сбора денег на нужды программистов (цель понятная и благородная). Суть компании описывается коротко и однозначно: "PSF – это организация, стоящая за Python".

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

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

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

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

Пакетный менеджер pip не позволяет фиксировать версии (нет аналога Gemfile.lock или package-lock.js), ошибается в сложных (но встречающихся на практике) случаях разрешения зависимостей, и, как вишенка на торте, не умеет отдельно скачивать метаданные.

То есть, на пальцах: чтобы понять, какую максимальную версию пакета А (заданную в манифесте как '1.*') можно использовать с пакетом B (версии, положим, тоже '1.*'), pip-у, в общем случае, требуется полностью скачать из PyPI все версии пакетов А и B соответствующие маске (1.1, 1.2, 1.2.2, 1.3, и т.д.).

Хорошо, эффективность выполнения PSF-ом своих прямых функций установили. Денег разработчикам сторонних решений (pipenv, например – приличный production-ready продукт, который можно просто взять и вмёрджить в основной дистрибутив python и закрыть вопрос) приниципиально решили не давать. На счетах PSF при этом скопилось 4 миллиона баксов. Чем же он занимается?

Достаточно посмотреть официальный список наёмных сотрудников, чтобы все вопросы снять. Полный список сотрудников и их обязанностей такой:
– директор (управление персоналом и трансляция воли совета директоров)
– счетовод, бухглатер и главный бухглатер (обязанности понятны)
– секретарь директора (сбор средств на благотворительных акциях, организация конференций)
– ивент-менеджер (организация конференций)
– Директор Инфраструктуры (заседание в комитетах, хостинг сайта python.org)

Про Директора Инфраструктуры, единственного айтишника среди всей команды, в официальном резюме сказано вот что: любит тако и кататься на велосипеде, притворяется что его любят кошки, а зовут его Ee W. Durbin III. Игра слов непереводимая и не до конца понятная, но ясно, что это что-то вроде "Вась И. Турбин Третий". При этом у человека есть и настоящее имя, конечно, в смысле по паспорту, но на лицевой странице фонда и в официальной переписке он предпочитает выступать Дурбин-Третьим. "Человек и пароход".

#programming #python

Понятно, что на всю Америку, несомненно, нашёлся бы хотя бы один программист, который мог бы за всю тусовку бухгалтеров пополам с ивент-менеджерами изображать (хотя бы из соображений естественной социальной маскировки) хардкорный технический уклон фирмы. Мол, ничего, что у нас тут собрались одни "организаторы", я за десятерых решаю вопросы развития языка и делаю по два PR в неделю, поэтому меня и одного хватит. Такие люди ведь есть. Назначение Дурбина-Третьего, поэтому, с такой специфической автобиографией, выглядит отнюдь не недоработкой, а демонстративным жестом: плевать нам на вас, гики, и так съедите и будете ходить на наши конференции по стагнирующему языку и платить деньги как миленькие, ещё и прыгать от радости. (И ходят, и платят, и прыгают.)

Итак, фирма занимается организацией ивентов. Команда подобралась сбалансированная.

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

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

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

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

Языки для бедных тоже нужны.

#programming #python

Недавно рассматривали организационную экосистему Python. В принципе, все всё правильно поняли.

Как точно резюмировал один из читателей: "постмодерн".

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

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

Перескочим сразу на следующую тему (в этой линии тем). JetBrains участвует в кампании по сбору средств на Django (деньги собирает отдельная организация) – отчисляет все поступления с продаж IDE PyCharm в Django Software Foundation. Дело стоящее, давайте в меру сил и доступных средств поучаствуем в популяризации хорошего языка и фреймворка.

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

#programming #django #python

В целом если вы видели один MVC фреймворк, вы видели их все. Переходя с Rails на Django (и наоборот) вы, может быть, ожидаете увидеть какие-то различия, но на самом деле всё в точности то же самое.

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

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

В Django опорный паттерн называется MVT, model-view-template. В Rails он называется MVC, model-view-controller. Разница только терминологическая: то что в Rails называют views (перемешанные фрагменты HTML-кода и управляющих операторов), в Django называют templates. То, что в Rails называют controllers (класс, обрабатывающий запрос) в Django называют views (может быть классом, а может быть отдельной функцией). Здесь достаточно один раз привыкнуть, задать риторический вопрос "зачем надо было всё перемешивать?", и дальше спокойно работать.

В Rails слово application, "приложение", синонимично слову project, "проект". То есть это вот весь код, простите за тавтологию, Rails-приложения, который вы храните в отдельном репозитории. В Django проторенными дорожками не ходят, поэтому там application это отдельный пакет внутри вашего проекта.

На пакетах (packages) стоит остановиться подробней. В Rails за вас работает система автоимпорта и весь код (при настройках по умолчанию) загружается в память при старте (на тонкостях останавливаться не будем).

Если в папке app/models/car.rb лежит класс Car, то вам достаточно в коде написать Car, и Rails его найдут.

В Django всё не так просто.

Во-первых, вам всегда надо вручную импортировать классы из пакетов: from car_service.models import Car. В этом есть плюс: IDE всегда знает, откуда что взялось. Минус: существенное увеличение boilerplate-а и когнитивной нагрузки на его обслуживание.

В строке импорта выше car_service это, в терминах Python, имя пакета (имя выбрано произвольно: допустим, мы делаем бэкофис для автомастерской). А в терминах DJango, это имя "приложения" (application). models.py – имя файла, где лежит исходный код класса Car. Да, в Django в один файл принято запихивать десяток классов. Это одно из многих проявлений знаменитого питоновского акцента на красоту и элегантность кода.

Для того, чтобы всё заработало, вам надо добавить строку "car_service" в массив подключенных приложений (INSTALLED_APPS) в settings.py (файл настроек проекта). (Кстати, термин application здесь в итоге близок тому, как он понимается в экосистеме Elixir/Phoenix.) В терминах Rails этому car_service нет прямого аналога, иногда что-то подобное можно назвать "ресурсом" (resource, в терминах REST), иногда bounded context (опять же в Phoenix более прямые аналоги).

Поэтому, переходя с Rails на Django, надо понять, что весь код программисты конкретного приложения разбили, произвольно, на набор вот этих пакетов-приложений, и модель Car вы найдёте в файле car_service/models.py, а модель User в папке accounts/models.py.

#programming #django #python

Питоновские пакеты, из-за обязательного явного импорта, могут экспортировать не только классы, но и переменные или константы:

# some_file.py

NUMBER = 1

# another_file.py

from .some_file import NUMBER
print(NUMBER) #=> 1

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

Как было сказано выше, в Django в роли "вьюх" (т.е., в терминах Rails, "контроллеров") могут выступать отдельные функции. А могут и классы. Первое называется function based views, а второе class based views.

Привыкшему к REST веб-разработчику сподручнее сразу использовать class based views, чтобы не получать очередного когнитивного диссонанса от использования конструкций вроде if request.method == 'POST' в мейнстримном фреймворке, созданном на самом элегантном языке программирования.

#programming #django #python