Мониторинг поддержки Python 3.10 в 360 самых популярных библиотеках.

На данный момент лишь 11.9% явно декларируют поддержку новой версии языка. Среди оставшихся 88% есть ещё некоторое количество библиотек, которые тестируются и работают на 3.10, но не выставили классификатор у себя в метаданных, поэтому не определяются этим сайтом (например, Flask, Jinja и все другие проекты Pallets). Большинство библиотек все-таки пока что не гарантирует работу на 3.10.

Что ж, подождём ещё пару месяцев! Должно стать уже сильно лучше, наверняка можно будет уже более-менее полноценно пользоваться.

https://pyreadiness.org/3.10/

PyCharm тоже выпустили видео в честь релиза Python 3.10.

Самая интересная часть с 16:19 — это где Łukasz Langa рассказывает, почему black не сможет полноценно парсить код на новой версии языка с match-case (пока что).

https://youtu.be/JteTO3EE7y0

#jetbrains

Причины пока что не обновляться до 3.10.

Некоторые из них уже не актуальны. Например, вчера на Docker Hub появились официальные образы с 3.10.

В любом случае, хорошим правилом считается дождаться первого релиза с фиксами, прежде чем обновлять прод (будет через полтора-два месяца). А экспериментировать можно и нужно уже сейчас!

https://pythonspeed.com/articles/switch-python-3.10/

Всякое бывает.

https://www.reddit.com/r/ProgrammerHumor/comments/q21o3d/poor_developers/

У меня вчера мир перевернулся, когда я попытался создать строку с одним бэкслешем при помощи r"\". Всё, во что я верил, оказалось ложью. Я даже сначала подумал, что у меня сломалась IDE, когда написанное вдруг начало светиться красным.

Обычно люди думают, что все бэкслеши в r-строках перестают быть экранирующими символами. Это не совсем так, потому что внутри строковых литералов люди часто зачем-то хотят использовать те же самые кавычки, в которых строка и записана. Чтобы это было возможным, нужно кавычки внутри литерала экранировать. Так что внутри r-строк бэкслеши в большинстве случаев просто символы, но перед кавычками они снова становятся экранирующими. А если тебе нужно сделать строковый литерал, который заканчивался бы на бэкслеш, то его тоже нужно заэкранировать (удвоить).

Так что самый короткий способ создать строку из одного бэкслеша — это всё-таки просто "\\". Raw строки тут никак не помогут.

Судя по результатам голосования, не только меня удивило такое поведение.

Даже в официальном FAQ есть такой пункт:

https://docs.python.org/3/faq/design.html#why-can-t-raw-strings-r-strings-end-with-a-backslash

А вы знали что у builtin функции iter() есть два варианта использования?

Первый, о котором знают все - вызывает у объекта метод __iter__() и возвращает результат.

А вот второй принимает Callable без аргументов и значение, на котором нужно остановиться. Можно применять, например, для чтения файлов блоками:
from functools import partial
with open('mydata.db', 'rb') as f:
for block in iter(partial(f.read, 64), b''):
process_block(block)

Более простой пример:
>>> a = (i for i in (1, 2, 3, 4, 5))
>>> list(iter(lambda: next(a), 4))
[1, 2, 3]

#python_cookbook #iter #nothabr #pydaily

Был бы я более питонистом, сразу бы пошел собирать из сорцов, но нет.

Вообще фигня клевая, по шагам проходишь с чекаута до рантайм штуковин, прям бери Python и фикси под свои нужды.

https://realpython.com/cpython-source-code-guide/#what-does-a-compiler-do

Офигенный читшит про новый структурный паттерн матчинг🐍

P.S. А за денюжку можно получить еще более подробную версию читшита: https://mathspp.gumroad.com/l/cheatsheet_match_statement

А вот ещё вдогонку статьи от того же автора, что сделал и читшит чуть выше.

Когда и как стоит использовать паттерн матчинг: https://mathspp.com/blog/pydonts/structural-pattern-matching-tutorial

И когда не стоит этим злоупотреблять и лучше отдать предпочтение другим инструментам: https://mathspp.com/blog/pydonts/structural-pattern-matching-anti-patterns

В 3.10 в модуль itertools добавилась функция pairwise. Кажется, more_itertools постепенно перетекает в стандартную библиотеку 😅

https://docs.python.org/3/library/itertools.html#itertools.pairwise

toolz — набор утилит для функционального программирования в Python.

Код: https://github.com/pytoolz/toolz/
Документация: https://toolz.readthedocs.io/

Содержит в себе множество различных функций. Частично пересекается с more_itertools и boltons, про которые я писал чуть выше.

Все функции можно разбить на три категории:
* itertoolz;
* functoolz;
* dicttoolz.

Самыми интересными на мой взгляд являются функции compose и curry, которые составляют основу для ФП. В документации подробно расписано, зачем всё это нужно.

Вот здесь, например, можно посмотреть как используется каррирование: https://blog.drewolson.org/declarative-validation (отсюда я, кстати, и узнал про эту библиотеку).

#library

☝️ это в тему про то, что Python вышел на первое место в рейтинге языков TIOBE, сдвинув Java и C на 2 и 3 место. Не слишком доверяю этому рейтингу, так что не считаю это каким-то большим достижением. Но всё равно приятно. И картинка забавная.

https://opennet.ru/55945/

Вышел стабильный релиз psycopg==3.0. Можно пробовать внедрять в свои проекты.

pip install --upgrade pip           # to upgrade pip
pip install psycopg[binary,pool]    # to install package and dependencies

🐍 + 🐘 = 🎉

https://twitter.com/psycopg/status/1447962001121157133?s=21

#psycopg

Хм, есть шансы, что шутки про GIL в Python могут уйти в прошлое.

Sam Gross — разработчик из Facebook — предлагает набор изменений, которые удаляют GIL и позволяют Python эффективно утилизировать разные ядра процессора при помощи потоков. Эти изменения слегка замедляют однопоточные программы (которых большинство), но чтобы «подсластить пилюлю» автор также предлагает набор оптимизаций, которые ускоряют питон в целом примерно на 10%. В итоге получается быстрее.

Сообщество активно обсуждает предложение в списке рассылки. Работоспособный форк 3.9 без GIL там тоже прилагается.

https://mail.python.org/archives/list/python-dev@python.org/thread/ABR2L6BENNA6UPSPKV474HCS4LWT26GY/

#gil

Для контекста. Ещё 14 лет назад Гвидо сказал, что не позволит удалять GIL ценой замедления однопоточных программ. К тому моменту уже было несколько попыток, которые замедляли однопоточные программы на 30-50%.

https://www.artima.com/weblogs/viewpost.jsp?thread=214235

А новость из поста выше как раз потому и новость, что нет ощутимой просадки по single-threaded перфомансу. Насколько мне известно, это пока что самая успешная из попыток выпилить GIL.

#gil

Нашлась ещё одна статья, которая популярно обьясняет суть предложенных изменений. А я попытаюсь пересказать своими словами.

Короче, самой большой проблемой при удалении GIL является сборщик мусора CPython, работающий по принципу счетчика ссылок. Важно, чтобы операции инкремента и декремента счетчика ссылок были атомарными, иначе сборщик мусора может либо удалить ещё используемый объект (и это будет segfault), либо пропустить уже неиспользуемый (утечки памяти). Если просто в тупую защитить операции со счетчиком ссылок при помощи какого-нибудь лока, то производительность интерпретатора сразу же сильно падает, потому что эти операции происходят очень-очень часто. Поэтому нужны более хитрые подходы. Автор предложения придумал три вещи (или скорее не придумал, а вдохновился в других языках).

1. Сделать два счетчика ссылок. Один (не атомарный, быстрый) будет считать количество ссылок внутри потока-владельца, который создал объект, а другой (атомарный, медленный) — количество ссылок во всех остальных потоках. Пока в главном потоке есть ссылки на объект, можно даже не проверять второй счётчик, потому что объект точно нельзя удалять. Когда в главном потоке больше не остаётся ссылок, а в других потоках они ещё есть, то сборщик мусора ориентируется на второй, медленный счётчик ссылок. Эта оптимизация основана на предположении, что большинство объектов используются лишь в рамках одного потока. Это то самое, что защищает однопоточные программы от большой просадки по производительности.

2. Объекты-синглтоны (None, True, False, Ellipsis), а также некоторые числа и строки, бессмертны, они остаются в памяти навсегда. Эти объекты используются практически повсеместно. Тем не менее, в нынешней реализации для них ведётся подсчёт ссылок, что является бессмысленной работой. Вот, предлагается не делать этого. Такие объекты будут помечаться специальным флажком, чтобы сборщик мусора даже не смотрел в их сторону, и подсчёт ссылок для них тоже не будет вестись.

3. Объекты модулей и функций не бессмертны, но они как минимум живут долго. Зачастую они ссылаются друг на друга, образуя циклы, так что счётчики ссылок все равно не помогут понять, когда они перестанут использоваться. Я не совсем понял суть, но кажется, что можно тоже упразднить подсчёт ссылок для таких объектов, и доверить очистку более мудрому и медленному сборщику мусора, который просыпается время от времени, останавливает мир и отлавливает объекты с циклическими ссылками. Это уже реализовано в CPython, если что.

Также были переработаны имплементации списков и словарей, а механизм аллокации памяти был заменён на другой, который лучше работает с многопоточными программами.

Ещё автор применил и другие оптимизации, наверное, чтобы его предложение не было сразу же зарублено на корню, потому что оно все-таки слегка замедляет однопоточный кейс. Скорее всего, эти оптимизации в любом случае попадут в CPython, даже если работу, связанную с GIL, отклонят.

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

https://lwn.net/SubscriberLink/872869/0e62bba2db51ec7a/

#gil #конспект