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

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

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

#dependency_injection

Выполняем:

$ pip install postgresql-wheel

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

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

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

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

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

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

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

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

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

#gil

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

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

#black

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

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

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

#black #django

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

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

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

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

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

#meme

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

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

#vim

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

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

“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

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

https://youtu.be/FW3_OPBxk2s

#jetbrains #pycharm

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

Попытался разобраться, благодаря чему Python 3.11 уже аж на 30% быстрее 3.10. Собрал небольшой синтетический микробенчмарк с делением чисел. И действительно сразу же видно, что даже на максимально простых примерах без каких-либо исключений 3.11 быстрее примерно на треть. В официальном ченджлоге не упоминается никаких таких оптимизаций, которые могли бы дать подобный эффект. Возможно, документацию пока просто не успели обновить. Возможно, это какой-то побочный эффект от ускорений, связанных с обработкой исключений. Похоже, надо идти в список коммитов в Git и искать ответы там 🤷‍♂️

По поводу "zero cost" exceptions. Разница между кодом вообще без исключений и кодом с блоком try..except, который ничего не ловит, действительно небольшая. Как утверждает официальный FAQ, такие блоки всегда были дешевыми. И в 3.11 эта разница действительно стала ещё меньше — 5 наносекунд против ~2 наносекунд. Тем не менее, цена всё ещё не нулевая. Наверное, именно поэтому автор этой оптимизации ставит кавычки вокруг "zero cost". Если же исключение возникает, то обе версии работают примерно с одинаковой скоростью.

Ссылки:
* детали моего наколеночного бенчмарка;
* идея бенчмарка взята из этого ответа.

Табличка с результатами моего бенчмарка. Видно, что 3.11 в принципе на всех проверенных кейсах работает быстрее.

Вывод: стало быстрее, а почему — я не понял 🤷‍♂️

okay.... https://susam.in/maze/infinitely-nested-dictionary.html