Библиотечка SQLModel все-таки вышла в глобальные тренды на GitHub, но пока только на дневном интервале. Если указать язык Python, то вообще будет в начале списка.

3500+ звёзд за три дня. Маэстро Рамирез снова на хайпе.

https://github.com/trending?since=daily

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

Сам Sebastián Ramírez утверждает, что работа над библиотекой заняла у него несколько месяцев исследований и экспериментов. Насколько я понял, до последнего момента эта разработка держалась в секрете, и лишь иногда проскакивали интригующие твиты на тему баз данных.

Как только автор опубликовал первую версию, он сам анонсировал это событие как можно шире — в твиттере на все свои 25к подписчиков, его пост на реддите тоже был тепло встречен сообществом. Затем подключилась сеть натренированных подпевал (типа меня), и анонс разошёлся по всем отдалённым уголкам интернета. Наверное, уже все питонисты слышали, что tiangolo сделал новую горячую штуку. Тысячи людей услышали, лишь сотни на самом деле попробовали. Но мы все всё равно уверены, что эта библиотека хорошая, удобная, полезная и обречена на успех, потому что "ну это же tiangolo, он плохо не сделает". Дальше эта библиотека наверняка появится во всех тематических новостных рассылках, а затем последует волна подкастов с автором про его опен-сорс проекты.

Я ни в коем случае не осуждаю Себастьяна за то, что он влияет на настроения в сообществе. Он всё делает правильно. Удачно хайпануть — это тоже талант, я считаю.

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

На гитхабе лежат тысячи проектов с единицами звёздочек. Некоторые из них, вероятно, решают распространённые проблемы, и делают это превосходно, но они так никогда и не станут популярными. Наверное, даже просто поделиться ссылкой на свой проект в какой-нибудь рассылке, как это в своё время сделали Линус Торвальдс и Гвидо ван Россум, сегодня уже может быть недостаточно. Для успеха в опен-сорсе лишь писать хороший код недостаточно, нужен маркетинг. Нужно создавать имидж, зарабатывать репутацию.

Кажется, что Себастьян Рамирез серьёзно относится к продвижению своих проектов. Например, мы знаем, что он всегда пишет очень обширную документацию для своих проектов, и он продолжает это делать для всех своих новых проектов прямо с самых ранних версий. Все кто пользовался его проектами, знают, что там везде работает автокомплит, и код благодаря этому пишется приятно, мы получаем хороший developer experience. Да, он специально это проверяет. Это всё репутация. Он собирает отзывы от пользователей (testimonials), и прикладывает их в самое начало документации. Возможно, маркетингом является даже то, как он использует эмодзи во всех коммитах, документации и сообщениях. Некоторым людям это нравится, это располагает. Например, какие эмодзи у вас возникают перед глазами, когда вы думаете о FastAPI? У меня это 🚀, 🎉 и ✨— крайне позитивные эмоции, потому что я много раз видел, как автор и другие люди используют именно их. Возможно, смешные закрученные усы являются частью имиджа, благодаря чему Себастьяна всегда легко узнать на конференциях. Запомнил бы я его внешность без этой яркой детали? Не уверен.

Отзывы про SQLModel пока что крайне положительные. Если верить в Hype cycle, то сейчас библиотека поднимается к пику раздутых ожиданий. Последует ли дальше разочарование? А было ли дно разочарования у FastAPI или оно все ещё находится на пике? Это всё крайне любопытно и даже забавно, и я продолжу за этим наблюдать. Ну и, конечно же, буду подливать масла в огонь по мере своих возможностей, чтобы посмотреть, что в итоге из этого всего хайпа выйдет 😊

"Ну вот написал я асинхронную функцию, а как тестировать?"

Почти что точно так же, как и обычные функции, но есть некоторые особенности:

https://tonybaloney.github.io/posts/async-test-patterns-for-pytest-and-unittest.html

В комментах скинули новый, набирающий популярность тестовый фреймворк ward, который в том числе умеет запускать асинхронные тесты без дополнительных плагинов. Очевидно, автор вдохновлялся pytest, поэтому получилось идейно похоже, но всё-таки иначе в деталях. Мне нравится, надо попробовать!

Жаль только, что никаких интеграций с IDE похоже пока нету. Вряд ли PyCharm и VSCode смогут рисовать зелёные треугольники напротив тестов в коде.

https://github.com/darrenburns/ward

Psycopg3 — новая долгожданная версия самого популярного и стабильного драйвера для PostgreSQL на питоне — зреет на наших глазах. Автор (Daniele Varrazzo) недавно выложил первый бета-релиз на настоящий PyPI. До этого были только релизы на тестовом PyPI.

https://www.psycopg.org/articles/2021/08/30/psycopg-30-beta1-released/

#psycopg

Курс CS50  от Гарварда и так был бесплатен и доступен на ютубе, но в этом году они сделали онлайн лекции доступными для всех через Zoom.
Если вы дано хотели войти в айти это отличный курс, вне зависимости от того посмотрите в лайф или в записи.

Темы:
Си
Структуры данных
Алгоритмы
Питон
SQL
html, css
Flask

Всего понемногу. Длится всего 10 недель. Начало 1 сентября.

https://cs50.harvard.edu/x/2021/zoom/

А бывало у вас такое, что какие-то библиотеки были установлены через системный пакетный менеджер (apt или dnf), а какие-то пришлось ставить через pip? Потом в какой-то момент всё ужасно перепутывается, дальше в попытках починить возникший хаос по подсказке из интернета делается что-то типа sudo pip uninstall <very_important_package_os_relies_on>, и... всё. Точка невозврата пройдена, дальше проще уже переустановить ОС, чем вернуть всё в рабочее состояние.

Недавно появился PEP 668, который призван решить эту проблему. Документ разграничивает области ответственности системных пакетных менеджеров, которые управляют питоном, и pip, так чтобы они не мешали друг другу. Грубо говоря, ребята хотят отучить pip ломать операционные системы. Если этот PEP примут, то отхватить проблем всё ещё будет можно, но сложнее, и везде будут предупреждающие сообщения, так что по крайней мере новички перестанут попадаться в эту ловушку.

https://lwn.net/SubscriberLink/867657/0efafb319ce20e3e/

Увидел недавно очередную внезапность с float'ами. Берётся список чисел:

>>> mylist = [
...  614.3,
...  453.44,
...  220.8,
...  514.32,
...  322.32,
...  330.3,
...  230.3,
...  518.32,
...  419.52]

И складывается, начиная сначала с одного конца, а затем с другого:

>>> sum(mylist) == sum(mylist[::-1])
False

И суммы не сходятся.

Тема уже избита до невозможности, и все вроде бы уже смирились, что арифметика над числами с плавающей точкой категорически сломана (ладно, она не сломана, она просто с погрешностями). В интернете особенно часто за эту особенность почему-то достаётся JavaScript'у, но на самом деле этим болеют все языки программирования, которые реализуют числа по стандарту IEEE 754, то есть практически все. Даже страничка с забавным доменом есть на эту тему: 0.30000000000000004.com.

Оказывается, что сложение чисел с плавающей точкой не реализует одно из математических свойств сложения — ассоциативность. То есть a + (b + c) не всегда равно (a + b) + c. То есть в зависимости от порядка, в котором складывать числа, погрешность может накапливаться по-разному. Для меня стало открытием, что арифметика сломана настолько.

Минимальный пример:

>>> ε = 1e-16 # small number
>>> print(left := (1 + ε) + ε)
1.0
>>> print(right := 1 + (ε + ε))
1.0000000000000002
>>> left == right
False

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

>>> import math
>>> math.fsum(mylist) == math.fsum(mylist[::-1])
True

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

🍁 Если погрешность для вас неприемлема, то конвертируйте ваши числа в decimal.Decimal — да, будет значительно медленнее, но зато точно:

>>> 0.1 + 0.2
0.30000000000000004
>>> from decimal import Decimal
>>> Decimal("0.1") + Decimal("0.2")
Decimal('0.3')

🍁 А если вы считаете деньги, то просто выражайте суммы в целых числах (центы и копейки вместо долларов и рублей) — так будет намного проще и надёжнее. Не используйте float для денежных расчётов! Если вы думаете, что погрешности у float начинаются только где-то в пятнадцатом знаке после запятой, то у меня для вас плохие новости — чем больше числа, тем больше и погрешности. Цена даже одной ошибки может быть очень высока 😬

В продолжение про float и его погрешности.

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

>>> 0.1
0.1

Но это число нельзя точно представить в двоичном виде, в любом случае это будет лишь аппроксимация, приближение. Так что то, что показал питон — это лишь округление, это чтобы не пугать людей. Можно посмотреть на точное значение, которое хранится внутри float, например, при помощи конвертации числа в decimal.Decimal:

>>> Decimal.from_float(0.1)
Decimal('0.1000000000000000055511151231257827021181583404541015625')

Кстати, именно поэтому Decimal лучше создавать из строк, например, из "0.1", а не из 0.1. Потому что если вы использовали float, то Decimal сохранит его значение максимально точно, то есть тоже будет лишь аппроксимацией, и все дальнейшие вычисления будут содержать эту изначальную погрешность.

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

>>> Decimal.from_float(10.0 ** 16)
Decimal('10000000000000000')
>>> Decimal.from_float(10000000000000000.1)
Decimal('10000000000000000')

В какой-то момент float вообще перестаёт мочь представлять точно даже целые числа, например, 10 ** 22 всё ещё представимо:

>>> Decimal.from_float(10.0 ** 22)
Decimal('10000000000000000000000')

А вот 10 ** 23 уже нет:

>>> Decimal.from_float(10.0 ** 23)
Decimal('100000000000000008388608')

Бабах! Ошибка на восемь миллионов, но это самая точная аппроксимация, которую можно выразить на 64 битах, выделенных под число (на самом деле, мантисса числа — самая важная часть — занимает лишь 53 бита). И это мы ещё даже никаких операций над числами не делали, просто их создаём.

Не знаю, есть ли на планете человек, у которого на счету лежит 10 ** 23 денег. Возможно, если конвертировать все накопления Джефа Безоса (самый богатый человек) в иранские риалы (самая дешевая валюта)... 🤔 Остаётся только надеяться, что его банк не использует float для хранения баланса.

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

Вот тут есть некоторые объяснения странностей float: https://docs.python.org/3/tutorial/floatingpoint.html

На Reddit проходит AMA сессия (ask me anything) с создателем и мейнтейнерами Black — это такой форматтер кода.

Например, оттуда я узнал, что Black все ещё парсит код при помощи старого LL-1 парсера, в то время как CPython с версии 3.10 уже полностью переключился на более продвинутый PEG-парсер по умолчанию (в 3.9 его можно было включить через флаг), благодаря чему и стали возможны все эти выкрутасы со сложными синтаксическими конструкциями, типа паттерн-матчинга. Похоже, Black был одной из причин, по которым было решено переписать парсер, но теперь у самого Black из-за этого будут сложности — придётся переписать много кода, чтобы поддержать 3.10.

https://www.reddit.com/r/Python/comments/plvtlx/were_the_core_team_behind_the_popular_python/

Цитата дня

Интересная серия постов в блоге StackOverflow про разработку софта в SpaceX — для управления ракетами, спутниками Starlink и всякими внутренними процессами, типа цепочек поставок и сборки аппаратов на конвейерах. Статьи в популярном стиле, технических подробностей не слишком много, но всё равно интересно.

Самые ответственные части пишутся, конечно, на C++ — например, ПО, которое работает непосредственно на ракетах и спутниках, потому что там нужно быстро реагировать и принимать решения. Но в местах, где производительность не критична, а также для прототипирования, используется Python. Ещё используются PostgreSQL, Docker, Kubernetes, Angular. Раньше было много чего на MS стэке — SQL Server, ASP.NET и прочее, но от этого решили отказаться в пользу открытых продуктов.

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

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

https://stackoverflow.blog/tag/software-in-space/

Ещё одна штука для форматирования кода. Она даже ещё более лютая, чем black. Объединяет в себе следующие тулзы:

* autoflake — удаляет неиспользуемые импорты и переменные;
* pyupgrade — применяет кучу рефакторингов и эвристик против использования старых и плохих подходов, заменяя их на новые и правильные;
* isort — сортирует импорты;
* black — форматирует код;
* pybetter, teyit, com2ann — применяет тривиальные рефакторинги, заменяет устаревшие методы на новые, делает из комментариев # type: int нормальные тайп-аннотации.

При этом штука не даёт вообще ничего настроить. Максимально тоталитарно!

https://github.com/Zac-HD/shed

Музыкальная пауза!

https://www.youtube.com/watch?v=hgI0p1zf31k

Ещё один комбайн для форматирования кода ufmt = black + usort (сортировалка импортов).

https://github.com/omnilib/ufmt

Оттуда я узнал про эту интересную альтернативу isort. В отличии от isort, оно не меняет форматирование (просто меняет импорты местами, не меняя сам код, не расставляя скобки и переносы строк) и не делает опасных рефакторингов (не меняет положение импортов относительно другого кода). Точно так же бьёт импорты на три секции — stdlib, 3rdparty, 1stparty.

https://github.com/facebookexperimental/usort

Кстати, PSF закрыл ещё одну свою вакансию, и теперь у нас есть оплачиваемый фулл-тайм проджект менеджер, который будет заниматься развитием PyPI и экосистемой пакетов в целом!

Эта позиция создана по инициативе и при финансовой поддержке со стороны Bloomberg. Они закоммитились выплачивать гранты минимум 2 года, так что и эта должность вероятно тоже просуществует как минимум пару лет.

https://pyfound.blogspot.com/2021/08/shamika-mohanan-has-joined-psf-as.html

Минутка сомнительного контента.

Я продолжаю заниматься цифровой археологией, изучая источники эпохи Великого Перехода на Python 3 (примерно 2010 — 2021 гг. н.э.). Без сомнения, это был очень болезненный процесс. Я прочитал уже много критики, но некоторые статьи меня до сих пор могут удивить. Например, вот этот пост "The Case Against Python 3" от Зеда Шоу (Zed Shaw).

https://learnpythonthehardway.org/book/nopython3.html

Цитаты:

> THERE IS A HIGH PROBABILITY THAT PYTHON 3 IS SUCH A FAILURE IT WILL KILL PYTHON.

> the Python project uses propaganda, social pressure, and marketing to convince you to use it

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

В интернете тогда знатно бомбануло по поводу этого поста. Вот здесь есть качественный ответ с разбором по пунктам: https://eev.ee/blog/2016/11/23/a-rebuttal-for-python-3/

В итоге автор всё-таки адаптировал свою книгу Learn Python The Hard Way для Python 3, хотя сопротивлялся до 2017 года. Кажется, после этого поста книге и перестали доверять в сообществе, её перестали рекомендовать, а автор в итоге закрыл её под пейволлом, хотя раньше она была доступна полностью бесплатно. Жаль, такие драмы никогда не идут на пользу общему делу. Но в них интересно в последствии копаться, хах.

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

Деды, если вы ещё живы, расскажите как оно было на самом деле? Что вы скажете о миграции на Python 3?

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

Чувак, который работал в Sony Pictures, в частности над Spider-Man: Homecoming, рассказывает как Python помогает на разных этапах производства фильма. Там ещё есть ссылки на целую серию постов про разбор разных фильмов. Чувак даже сделал курс на Udemy, где обучает как скриптовать в Maya на питоне.

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

https://www.gfx.dev/python-for-feature-film