Сергей Вариасов. Почему мы написали еще один фреймворк для Python

Ждем вас на наших конференциях:
2 февраля 2024 - EkbPy
26-27 июля 2024 - PyCon
Сергей Вариасов
Техлид направления Python, ЕвразТехника ИС
Почему мы написали еще один фреймворк для Python

[@oleggarshin251]

Интересный доклад, Сергей, спасибо!

[@windachae4778]

Хороший доклад, слушать приятно

[@vsevolodqq]

Ломаете стереотипы о заводах и их подходах к работе) Оч. круто, спасибо!

[@yodapunishes]

Очень интересно, но работать бы я к вам не пошел 😁

[@Ca1vema]

В питоне чистая архитектура работает плохо. Почему? Потому что asyncio - это библиотека, а не фича языка. Поэтому ты не можешь эффективно создавать интерфейсы, которые возможно будут работать с IO, либо ты изначально закладываешь свое приложение на async, либо "сосешь бибу" в будущем.

[@a1d4rg]

async/await синтаксис не ограничен asyncio. Никто не запрещает писать асинхронный код на Anyio, который может запущен как с asyncio, так и с trio.

[@Ca1vema]

@@a1d4rg спасибо за информацию, но я не про это. Возьми классический подход для работы с хранимыми данными в DDD - это репозитории. Во время разработки и тестов я могу заинжектить репозиторий, который данные хранит просто в поле класса, но когда придётся прикручивать БД я буду ограничен только синхронными драйверами, потому что мой код синхронный. Соответственно изначально нужно делать приложение, которое будет работать с async/await, и не важно что там под капотом используется.

[@a1d4rg]

@@Ca1vema Да, это так, к сожалению. В дополнение, если писать асинхронный код, то любые вызовы синхронных библиотек придётся выносить в тред, чтобы не блокировать event loop. Но мне понравилась идея изначально делать все IO функции и методы, которые ходят в сеть или БД сразу с асинхронными сигнатурами. В том числе и интерфейсы. То есть когда пишёшь код и вызываешь await, то сразу понимаешь, что ага - это функция ходит в сеть или на диск. Возьмём ваш пример с репозиториями. Если вы пишите синхронный код, скажем на джанге, то асинхронные драйвера вам скорее всего ни к чему, и все методы репозитория будут синхронными. А если вы сразу пишете асинхронный код, то зачем делать методы репозитория синхронными, если подразумевается, что они в них вы будете ходить в сеть или на диск?

[@markervictor]

Тоже уже полгода нахожусь в поисках относительно того, как гексагональную архитектуру с DDD можно поженить с Python. Практически всё действительно сводится к велосипедам, т. к. нет готовых реализаций паттернов, которые описаны в книгах. А ещё сложнее от того, что в рамках питона некоторые вещи, реальные для Java, Kotlin или.NET, просто нереально реализовать из-за более слабой системы типов, своего видения ООП, дурацкой системы импорта и подобного.

[@MichioSempai]

Потому что в python не нужно то, что нужно в типизиоуемых языках. Di по сути это попытки втащить в типизируемые языки элементы интропретации, зачем это в и так в интропретируемом языке

[@markervictor]

Можете пояснить чем DI похож на интерпретацию? Ничего не мешает руками писать DI контейнеры как на питоне, так и на любом другом языке. Просто это не так удобно, как когда есть готовое универсальное решение. Для питона оно было (dependency-injector), но уже два года не поддерживается

[@yodapunishes]

Что из себя представляет сам фреймворк по сути не сказано ни слова, только про зависимости и DI. Про Gevent вообще сомнительно. Именно по той причине, что озвучил автор, мы от него отказались: он не в полной мере даже psycopg2 поддерживает, что уж говорить про другие библиотеки, написанные на Си