Со slots и frozen dataclass кодген работает нормально: генерится cls(dep0, dep1, …), объект создаётся через обычный init/dataclass-init, и Injex ничего не присваивает в инстанс напрямую.
Но все такие ломается одно - property-инъекция: она делает setattr после конструирования, поэтому на frozen происходит FrozenInstanceError, на slots - AttributeError: no dict. Тут дело не в кодгене, так упадёт любой setattr подход. Для slots/frozen нужно брать конструкторную инъекцию, а property-инъекцию там просто не применять))
Резолв сейчас синхронный. Для FastAPI можно: собрать контейнер один раз в lifespan и резолвить синхронно, а async живёт внутри методов уже собранных сервисов, а не на этапе конструирования, так что для обычной проводки async-резолв не нужен. Чего Injex сознательно не делает, так это управление жизненным циклом async-ресурсов, тут dishka/dependency-injector сильнее. Полноценный async-резолв с ресурсами запланирован на будущее.
По механике мы в одну сторону смотрим - разница в том, что вы кодгените обёртку на конструктор, а я всю транзиентную цепочку разом.
Про transient как "костыль": - у вас скоуп-центрично: scoped переиспользуется в скоупе, и этого достаточно. - у меня lifetime-центрично (singleton/transient/scoped), и transient - новый на каждый вызов.
Не возьмусь утверждать, что лучше. Ваш "scoped ничем не хуже" - вполне рабочий аргумент.
Прогнал dishka на том же графе: manual 0.264, injex 0.407, dishka 0.755, wireup same-scope 0.935, dependency-injector 1.721. Конечно, важна оговорка: граф синхронный, и сила dishka в async-ресурсах и явных scope, которых тут нет.
Injex компилирует не весь граф в одну функцию, а только транзиентную цепочку. Листья - синглтоны, scoped, инстансы, остаются отдельными переиспользуемыми creators: синглтон в плоской функции - один вызов геттера, посчитанный раз, а не заинлайненная рекурсия. А всё, что компилятор не тянет (фабрики, property-инъекция, инъекция контейнера, циклы), честно откатывается на путь с обёрткой на узел / интерпретатор. Так что это скорее гибрид, чем одна мегафункция.
Соглашусь, на глубоких или широких транзиентных графах сгенерированная функция растёт, и компиляция обёртки на конструктор (как у вас) заметно лучше композится с кэшем, обработкой ошибок, инструментацией, будущими фичами и тд. Трейсбэк в плоской функции тоже менее гранулярный. Я оптимизировал узкий частый случай и оставил фоллбэк, но за гибкость это плата.
Спасибо, что навели на dishka, допишу в бенчмарк и вернусь с цифрой.
А можете подробнее про вашу обёртку на конструктор? Это кодген через exec или сборка замыкания?
Информация
В рейтинге
1 186-й
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Со slots и frozen dataclass кодген работает нормально: генерится
cls(dep0, dep1, …), объект создаётся через обычный init/dataclass-init, и Injex ничего не присваивает в инстанс напрямую.Но все такие ломается одно - property-инъекция: она делает setattr после конструирования, поэтому на frozen происходит FrozenInstanceError, на slots - AttributeError: no dict. Тут дело не в кодгене, так упадёт любой setattr подход. Для slots/frozen нужно брать конструкторную инъекцию, а property-инъекцию там просто не применять))
Резолв сейчас синхронный. Для FastAPI можно: собрать контейнер один раз в lifespan и резолвить синхронно, а async живёт внутри методов уже собранных сервисов, а не на этапе конструирования, так что для обычной проводки async-резолв не нужен. Чего Injex сознательно не делает, так это управление жизненным циклом async-ресурсов, тут dishka/dependency-injector сильнее. Полноценный async-резолв с ресурсами запланирован на будущее.
По механике мы в одну сторону смотрим - разница в том, что вы кодгените обёртку на конструктор, а я всю транзиентную цепочку разом.
Про transient как "костыль":
- у вас скоуп-центрично: scoped переиспользуется в скоупе, и этого достаточно.
- у меня lifetime-центрично (singleton/transient/scoped), и transient - новый на каждый вызов.
Не возьмусь утверждать, что лучше. Ваш "scoped ничем не хуже" - вполне рабочий аргумент.
Прогнал dishka на том же графе: manual 0.264, injex 0.407, dishka 0.755, wireup same-scope 0.935, dependency-injector 1.721. Конечно, важна оговорка: граф синхронный, и сила dishka в async-ресурсах и явных scope, которых тут нет.
Injex компилирует не весь граф в одну функцию, а только транзиентную цепочку. Листья - синглтоны, scoped, инстансы, остаются отдельными переиспользуемыми creators: синглтон в плоской функции - один вызов геттера, посчитанный раз, а не заинлайненная рекурсия. А всё, что компилятор не тянет (фабрики, property-инъекция, инъекция контейнера, циклы), честно откатывается на путь с обёрткой на узел / интерпретатор. Так что это скорее гибрид, чем одна мегафункция.
Соглашусь, на глубоких или широких транзиентных графах сгенерированная функция растёт, и компиляция обёртки на конструктор (как у вас) заметно лучше композится с кэшем, обработкой ошибок, инструментацией, будущими фичами и тд. Трейсбэк в плоской функции тоже менее гранулярный. Я оптимизировал узкий частый случай и оставил фоллбэк, но за гибкость это плата.
Спасибо, что навели на dishka, допишу в бенчмарк и вернусь с цифрой.
А можете подробнее про вашу обёртку на конструктор? Это кодген через exec или сборка замыкания?