Асинхронность — в django

[GamePad64]

Форк django абсолютно точно никто не захочет делать. Такое количество инструментов, которые заточены именно на django переделывать очень дорого.

Пока что orm не асинхронный, но можно пользоваться костылём sync_to_async из asgiref

[abetkin]

Форк это не то чтобы какое-то важное решение для развития проекта, это просто технический приём. А инструменты и так нужно всё время переделывать, например, поддержка django в PyCharm ломается на ветке main (сторонники rolling release сказали бы, что в этом случае, она сломана вообще)

[vsh797]

из-за того, что для запросов в базу нужно явно писать await, на ленивых запросах в базу, выполняющихся магически при доступе к атрибутам, наверно, придётся поставить крест.

Явное, конечно, лучше, чем неявное. Но если бы вызов await сделали поведением по умолчанию, то обратную совместимость было бы куда легче сохранить.

[abetkin]

Разве что, обратную совместимость в головах разработчиков :) Потому что доступ к related атрибутам через await ломает обратную совместимость сразу

[vsh797]

Даже если б await ставился по дефолту? В чем тогда может возникнуть проблема?

[abetkin]

не знаю, что Вы имеете в виду, но await по дефолту означает, что вместо obj.related_obj мы всегда пишем `(await obj.related_obj)`, иначе никак. Слово await нельзя пропустить, если мы хотим, чтобы вызов потенциально обращался к базе

[vsh797]

Дефолтный await значит, что его не нужно указывать. Он применяется к вызовам async по умолчанию. Наоборот, если нужно, чтобы программа не ждала результата, необходимо указывать спецслово.

[katletmedown]

видимо есть ряд причин, почему джанго годами не переводили в новые реалии. рискну предположить, что некоторые фреймворки, сколько не ностальгируй, пора просто отпустить, приложить усилия к развитию современных

[abetkin]

У меня нет ни капли ностальгии по django. Просто это такой челленндж - добавить туда асинхронность. А для современного фреймворка такого бы не было :)

[baldr]

Немного опоздал с комментарием, но вот такой важный момент для совместимости - как раз "ленивые" вычисления, которые позволяют писать код вида:

johns = Person.objects.filter(first_name="John")
john_smiths = johns.filter(last_name="Smith")
print(john_smiths.count())  # первый запрос
print(john_smiths)  # второй запрос

Запросов в базу будет только два и, более того, каждый из queryset мы можем передать куда-то дальше и добавить к нему еще вызовов (агрегация, и тп). То есть await мы должны ставить только для, например, __repr__ метода.

Однако для многих операций джанго может внутри делать отдельные запросы и в таких случаях методы должны быть объявлены как async , что накладывает условия на их вызов. И может быть сложно портировать код с такими цепочками.

А еще могут быть свойства (@property), которые, все-таки, методы и там вообще непонятно как их с await вызывать.

Еще добавляет непонятностей широкое использование классов и миксинов. В конструкторе формы обратиться к модели чтобы заполнить поля? Да везде! Но как определить async def __init__ ? И как вызывать super()? То же самое и с вьюшками - делаем ли все методы async чтобы не запоминать каждый раз как вызывать родительский метод при наследовании?

Выходом могло быть использование Promise-функций как принято в Javascript, например.

Как ни ужасно это признать, но, наверное, надо задуматься о том, что все достоинства джанги, при переходе на async/await внезапно тяжелым грузом начинают ее тормозить. При попытке дописать эту поддержку в существующий код мы получим страшного монстра, которым никто не захочет пользоваться. Не получится переписать только джанго и не трогать пользовательский код.

Сейчас уже хорошо начали подниматься проекты типа FastApi/Starlette и у них есть много хороших находок (и много нехороших). Я думаю что стоит оставить Django синхронной как есть и просто добавлять минорные изменения. Также добавить возможность частичной работы с async для новых библиотек, но не переписывать orm и view.

Имеет смысл начать просто новый проект движка со всеми хорошими идеями из джанги и заодно выкинуть все легаси.