Сергей Вариасов. Почему мы написали еще один фреймворк для Python
HTML-код
- Опубликовано: 27 мар 2024
- Ждем вас на наших конференциях:
2 февраля 2024 - EkbPy
26-27 июля 2024 - PyCon
Сергей Вариасов
Техлид направления Python, ЕвразТехника ИС
Почему мы написали еще один фреймворк для Python
Интересный доклад, Сергей, спасибо!
Хороший доклад, слушать приятно
Ломаете стереотипы о заводах и их подходах к работе) Оч. круто, спасибо!
Очень интересно, но работать бы я к вам не пошел 😁
Тоже уже полгода нахожусь в поисках относительно того, как гексагональную архитектуру с DDD можно поженить с Python. Практически всё действительно сводится к велосипедам, т. к. нет готовых реализаций паттернов, которые описаны в книгах. А ещё сложнее от того, что в рамках питона некоторые вещи, реальные для Java, Kotlin или.NET, просто нереально реализовать из-за более слабой системы типов, своего видения ООП, дурацкой системы импорта и подобного.
Потому что в python не нужно то, что нужно в типизиоуемых языках. Di по сути это попытки втащить в типизируемые языки элементы интропретации, зачем это в и так в интропретируемом языке
Можете пояснить чем DI похож на интерпретацию?
Ничего не мешает руками писать DI контейнеры как на питоне, так и на любом другом языке. Просто это не так удобно, как когда есть готовое универсальное решение. Для питона оно было (dependency-injector), но уже два года не поддерживается
В питоне чистая архитектура работает плохо. Почему? Потому что asyncio - это библиотека, а не фича языка. Поэтому ты не можешь эффективно создавать интерфейсы, которые возможно будут работать с IO, либо ты изначально закладываешь свое приложение на async, либо "сосешь бибу" в будущем.
async/await синтаксис не ограничен asyncio. Никто не запрещает писать асинхронный код на Anyio, который может запущен как с asyncio, так и с trio.
@@a1d4rg спасибо за информацию, но я не про это.
Возьми классический подход для работы с хранимыми данными в DDD - это репозитории.
Во время разработки и тестов я могу заинжектить репозиторий, который данные хранит просто в поле класса, но когда придётся прикручивать БД я буду ограничен только синхронными драйверами, потому что мой код синхронный. Соответственно изначально нужно делать приложение, которое будет работать с async/await, и не важно что там под капотом используется.
@@Ca1vema Да, это так, к сожалению. В дополнение, если писать асинхронный код, то любые вызовы синхронных библиотек придётся выносить в тред, чтобы не блокировать event loop. Но мне понравилась идея изначально делать все IO функции и методы, которые ходят в сеть или БД сразу с асинхронными сигнатурами. В том числе и интерфейсы. То есть когда пишёшь код и вызываешь await, то сразу понимаешь, что ага - это функция ходит в сеть или на диск.
Возьмём ваш пример с репозиториями. Если вы пишите синхронный код, скажем на джанге, то асинхронные драйвера вам скорее всего ни к чему, и все методы репозитория будут синхронными. А если вы сразу пишете асинхронный код, то зачем делать методы репозитория синхронными, если подразумевается, что они в них вы будете ходить в сеть или на диск?
Что из себя представляет сам фреймворк по сути не сказано ни слова, только про зависимости и DI. Про Gevent вообще сомнительно. Именно по той причине, что озвучил автор, мы от него отказались: он не в полной мере даже psycopg2 поддерживает, что уж говорить про другие библиотеки, написанные на Си