🐍 Привет, питоняги!

Pytup уже завтра!
Начало в 18-00 по МСК, онлайн.
Регистрируйтесь, ссылочка на трансляцию придет вам на почту

🤗 Вова покажет нам как дружить типы и ide
🧬 Надя покажет как она умеет "готовить" мутации
🗞 Напоследок узнаем свежие новости из мира питона от Андрея

ЗЫ запись будет, да 🎥

Это уже сегодня, если что!

А слышали когда-нибудь про RustPython?

Это интерпретатор Python, написанный на Rust 🦀 с нуля. Он компилируется в том числе и в WebAssembly, можно поиграться с ним прямо в браузере вот здесь.

Проект пока что находится на ранних стадиях разработки, но недавно у них случился большой успех — теперь работает pip и можно устанавливать пакеты!

https://rustpython.github.io/blog/2021/01/26/pip-support.html

2.7 все ещё популярнее, чем 3.9.

https://www.reddit.com/r/Python/comments/pb5j08/even_after_almost_2_years_migration_to_python_3/

P.S. Подозреваю, что где-то открылся портал в мультивселенную, и в наш PyPI проникло 429 наркоманов из мира, где есть Python 2.8.

lona-web-org/lona - очень любопытный фреймворк, который позволяет писать веб-приложения полностью на пайтоне. Ни строчки на js впредь! 😁

from lona.html import HTML, Button, Div, H1
from lona import LonaApp, LonaView

app = LonaApp(__file__)

@app.route('/')
class MyView(LonaView):
    def handle_request(self, request):
        message = Div('Button not clicked')
        button = Button('Click me!')

        html = HTML(
            H1('Click the button!'),
            message,
            button,
        )

        self.show(html)

        # this call blocks until the button was clicked
        input_event = self.await_click(button)

        if input_event.node == button:
            message.set_text('Button clicked')

        return html


app.run(port=8080)

#github #github_explore #nothabr #pydaily

Что бы вы поменяли в Python?

Библиотечка 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/

Цитата дня