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

Достаточно сильные аргументы против вставки значений напрямую в SQL-запросы.

Документация psycopg снова радует. С каждой версией её становится всё интереснее читать.

#psycopg

Список = динамический массив

Если в массиве под списком остались свободные места, то метод .append(item) выполнится за константное время — достаточно записать новое значение в свободную ячейку и увеличить счетчик элементов на 1:

def append(self, item):
  self.array[self.length] = item
  self.length += 1

Но что делать, если массив уже заполнен?

Приходится выделять память под новый массив, побольше, и копировать все элементы старого массива в новый (картинка прилагается).

Примерно так:

def append(self, item):
  if self.length == self.capacity:
    self._resize(self.capacity*2)
  self.array[self.length] = item
  self.length += 1

def _resize(self, new_cap):
  new_arr = (new_cap * ctypes.py_object)()
  for idx in range(self.length):
    new_arr[idx] = self.array[idx]
  self.array = new_arr
  self.capacity = new_cap

_resize() — затратная операция, так что новый массив создают с запасом. В примере выше новый массив в два раза больше старого, а в питоне используют более скромный коэффициент — примерно 1.12.

Если удалить из списка больше половины элементов через .pop(), то питон его скукожит — выделит новый массив поменьше и перенесет элементы в него.

Таким образом, список все время жонглирует массивами, чтобы это не приходилось делать нам ツ

Предложение выпилить GIL продолжают активно обсуждать.

На ежегодный Python core development sprint пригласили Sam Gross (автор nogil), и задавали ему много разных вопросов. Все под впечатлением. Всерьёз обсуждается вливание этого экспериментального форка в основной код CPython, но спешить с этим точно не будут, потому что изменения такого масштаба в интерпретаторе потребуют адаптации многих библиотек и пользовательского кода.

Изменение крупное, но если его добавлять небольшими кусками и растянуть этот процесс на несколько лет, то получится избежать Python 4. А Python 4 никто не хочет.

Сэма пригласили присоединиться к числу core-разработчиков интерпретатора. Łukasz Langa будет его менторить.

Пока что всё выглядит очень оптимистично. Ждите Python 3.20 без GIL 😅

https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/

#gil

Пару дней назад опубликовали черновик PEP 671.

Предлагается добавить синтаксис для значений по умолчанию, вычисляемых прямо перед выполнением функции (late-bound function argument defaults). Грубо говоря, можно будет в качестве дефолтного значения указать лямбда-функцию из одного выражения, в которой будут доступны все предыдущие аргументы. Это позволит более компактно выражать зависимости между аргументами.

Например, вместо вот такого:

# Very common: Use None and replace it in the function
def bisect_right(a, x, lo=0, hi=None, *, key=None):
    if hi is None:
        hi = len(a)

    ...

Можно будет написать вот такое:

def bisect_right(a, x, lo=0, hi=>len(a), *, key=None):
    ...

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

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

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

#pep

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

Владислав Лаухин — Применение Dependency Injection в Python

https://youtu.be/qfMWyStoyS4?t=3300

* Dependency Injection — полезный подход, но в Python-сообществе эта тема недооценена, потому что у нас (наверное, по историческим причинам) устоялись другие практики. Например, Django и Flask — самые популярные веб-фреймворки, не используют этот подход вообще, он не упоминается в документации, поэтому многие питонисты про такое могут даже не знать. Вместо этого у нас в ходу глобальные переменные, которые импортируются из всяких неожиданных мест.
* В терминах и аббревиатурах тоже есть путаница и непонимание: Dependency Inversion, Inversion of Control и Dependency Injection — это разные вещи.
* Dependency Injection (дальше просто DI) уменьшает связанность кода в системе, делает его гибче, расширяемее, его становится легче изменять и покрывать тестами.
* DI не стоит использовать везде. Например, это не нужно в исследовательских проектах (RnD), прототипах и небольших скриптах. Легаси-код переписывать на DI тоже не всегда обоснованно, усилия могут не окупиться.
* Встроенная система зависимостей в FastAPI отлично реализует принцип DI и решает проблемы, пользуйтесь ей. Однако, если вы пишете не HTTP API, вам придётся искать другой способ внедрять зависимости.
* Докладчик с командой попробовали несколько реализаций DI на Python, но остановились на dependency_injector, и им очень нравится. Внедрили уже в половину своих проектов. Не всё идеально, но плюсы перевешивают минусы.
* Тесты стали значительно проще. Уменьшилось количество манкипатч/моков, благодаря чему тесты перестали ломаться сотнями штук от каждого рефакторинга.
* Выводы: DI — круто, dependency_injector — огонь, тестировать код — важно.

#конспект #dependency_injection

Доклад про инъекцию зависимостей в питоне от создателя dependency_injector.

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

#dependency_injection