У меня вчера мир перевернулся, когда я попытался создать строку с одним бэкслешем при помощи 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 #конспект

На PyPI стали появляться первые сборки пакетов (wheel) для Linux-дистрибутивов на основе musl libc. То есть да, скоро в контейнеры на основе Alpine Linux вероятно можно будет перестать ставить кучу разных инструментов для сборки.

Но сильно не радуйтесь, потому что pip всё равно ещё не умеет ставить такие колёса.

Пока что я такое заметил только у cryptography: https://pypi.org/project/cryptography/35.0.0/#files

А вообще это PEP 656, и он уже принят, так что полная поддержка всеми нужными инструментами — теперь лишь вопрос времени: https://www.python.org/dev/peps/pep-0656/

Все уже успели обсудить новые фишки в Python 3.10, такие как ускорение работы базовых типов, удобная типизация и особенно новый паттерн матчинг.
Только ленивый не рассказывал про паттерн матчинг!
Давайте я прикинусь ленивым (но это не так😉) и не буду повторяться. Расскажу про другое нововведение.
В противовес мега полезному pattern matching эта штука, на первый взгляд, имеет сомнительную полезность🧐

В Python 3.10 у типа int появился новый метод int.bit_count().
Что он делает? Возвращает количество единиц в битовом представлении числа.
Что? Зачем? Почему? 😭❓😱

Это не bit_length(), возвращающий количество бит, необходимых для записи данного числа.
И это не struct.calcsize(I), возвращающий количество байт, в которые точно поместится любой int.
Зачем нам количество ненулевых бит в битовом представлении? Особенно когда новый метод это просто эквивалент строки:

bin(num).count("1")

Цитата из слов автора.

An efficient popcount would be useful for numerics, parsing binary formats, scientific applications and others.

Эта функция называется Population Count (подсчёт популяции). Применяется в алгоритмах теории информации. Почитайте про Теорию Хэминга чтобы понять чуть больше чем сейчас.
Если коротко, это такие алгоритмы, помогающие быстро определить схожесть или различие строк основываясь на их битовом представлении.

Этим применение не ограничивается. Подсчет единиц может быть полезен при работе с битовыми картами.
В Redis тоже есть подобная команда.

Как считаете, это маленькая удобная функция делающая Python ближе к научному сообществу или бесполезная трата места в документации?

#libs

PSF и JetBrains открыли свой ежегодный опрос про экосистему Python. Погнали заполнять!

https://surveys.jetbrains.com/s3/c1-python-developers-survey-2021

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

Умеет собирать множество различных метрик, например:
* количество строк, использованных операторов, комментариев;
* цикломатическая сложность;
* maintainability index.

По этим метрикам позволяет находить, например, самые сложные файлы в репозитории, которые сильнее всего хотят быть отрефактореными. Умеет пробегать историю изменений вглубь и оценивать, как метрики меняются со временем.

Можно интегрировать wily в качестве хука в Git, либо в CI. Честно говоря, это не кажется мне такой уж хорошей идеей, потому что мы часто осознанно хотим усложнить код, добавляя в проект новые фичи. Код вообще зачастую становится лишь сложнее. Было бы странно постоянно ронять CI из-за этого.

Но тулза всё равно полезная в информационных целях. Можно периодически её запускать, чтобы оценивать, как меняется проект. А ещё можно строить разные графики.

source: https://github.com/tonybaloney/wily
docs: https://wily.readthedocs.io/en/latest/index.html

#tool #wily

Вот, например, такие графики оно строит.

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

#tool #wily