Питонические атаки

Pyjion — проект по скрещиванию ванильного CPython с JIT-компилятором из .NET — получил релиз с круглым номером 1.0.

Напомню:
* по идее этот проект может запускать любой валидный код на Python, включая все библиотеки с нативными модулями (numpy, pandas, psycopg и так далее) без пересборок и каких-либо дополнительных действий;
* работает с самым обычным CPython 3.10;
* работает на Windows, Linux и macOS;
* устанавливается через pip, но будет рассчитывать, что в системе есть компилятор .NET 6;
* всё, что нужно, чтобы магия начала действовать — импортировать pyjion, вызвать pyjion.enable() перед основным кодом программы.

Пока что проект не умеет работать с контекстными менеджерами и async/await. Но это не значит, что он не сможет запустить такой код. Просто JIT-компиляция для функций с такими инструкциями не произойдёт, и они будут работать в обычном интерпретируемом режиме.

Кто-нибудь уже пробовал? Ускорило?

https://www.trypyjion.com/

#pyjion #jit

Полезный доклад от Андрея Власовских — лида команды PyCharm в JetBrains — про то, как быстрее и умнее редактировать код. В целом, Андрей показывает довольно базовые вещи, которые логично было бы ожидать от IDE. Проблема в том, что многие люди не знают, что их IDE всякое такое умеет, и запускают (относительно) тяжелую среду разработки, чтобы пользоваться ей просто как блокнотом с подсветкой кода. Не надо так, IDE намного умнее. Нужно лишь запомнить один самый главный хоткей — Find Action!

https://youtu.be/FW3_OPBxk2s

#jetbrains #pycharm

“Zero-cost” exceptions are implemented. The cost of try statements is almost eliminated when no exception is raised. (Contributed by Mark Shannon in bpo-40222.)

Наконец-то сделали поддержку "бесплатных" исключений. Под бесплатностью имеется в виду что блок try не будет потреблять практически никаких ресурсов, если в нём не возникнет исключение. Во многих других языках это уже давно есть.
Мне кажется что только одна эта оптимизация поспособствовала значительному ускорению 3.11.

#pydaily

5 ноября вышла вторая альфа Python 3.11 и по мнению людей, которым можно доверять, 3.11 на ~30% быстрее чем 3.10.

В первую очередь рост производительности это работа над идеями по оптимизации в рамках Faster CPython Project. Узнать о новых фичах в 3.11 можно по ссылке.

Всячески рекомендую ютуб-канал "Диджитализируй!". Он периодически снимает классные видео про Python. А сегодня я нашёл там настолько полезное видео, что решил даже запостить его сюда, чтобы в следующий раз, когда беда вдруг снова внезапно меня настигнет, оно было под рукой.

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

#vim

Surprisingly at the top of that curve is again 'no types'

https://twitter.com/fasterthanlime/status/1248025337235210243?s=20

#meme

There should be one-- and preferably only one --obvious way to do it.

А какие ещё вы знаете примеры нарушения этого принципа? Желательно в стандартной библиотеке.

«Прежде всего, дзен Python говорит, что любое решение должно быть единственное. Поэтому в Python всего минимум по три.»

В связи с чем проект Django собирается начать форматировать свой код при помощи black.

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

https://twitter.com/adamchainz/status/1455850491519254531?s=21

#black #django

Автоформаттер black принял «политику стабильности». В 2022 ожидайте стабильный релиз.

https://twitter.com/llanga/status/1455496802812239876?s=21

#black

Обсуждения выпиливания GIL продолжаются.

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

То, что уже обсуждаются уже конкретные детали плана, заставляет меня верить, что в основном идея удаления GIL обсуждена и принята.

https://discuss.python.org/t/nogil-mode-and-extensions/11546/11

#gil

Ваш питон тоже проверяет ваш код?)

Выполняем:

$ pip install postgresql-wheel

И теперь у нас в виртуальном окружении есть полноценный PostgreSQL! Изолированный, уже скомпилированный. Для установки не потребовалось sudo.

Теперь можно программно запускать и удалять сервера БД. Полезно, например, для тестов, когда тесты сами могут создать себе такую базу, которая им нужна, сделать своё дело и замести все следы. В комплекте даже есть фикстура для pytest.

Сборки пока что публикуются только для Linux, следовательно, на других ОС это работать не будет.

https://github.com/michelp/postgresql-wheel

Классическая статья про DI от Мартина Фаулера.

https://martinfowler.com/articles/injection.html

#dependency_injection

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

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

#dependency_injection

Воскрешу из сохранённых сообщений конспект доклада с 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

Пару дней назад опубликовали черновик 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

Предложение выпилить 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

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

Если в массиве под списком остались свободные места, то метод .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(), то питон его скукожит — выделит новый массив поменьше и перенесет элементы в него.

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