Здравствуйте, дорогие читатели! Сегодня - ещё одна статья из рубрики джангологии.

Раньше я уже писал о своих идеях (1 и 2) о том, как сделать django асинхронным. Они основывались, вслед за sqlalchemy, на использовании гринлетов. Несмотря на то, что proof-of-concept был успешно получен, а трудностей - встречено меньше, чем ожидалось, я всё-таки отказался от этого подхода. Во-первых, он уже применяется в sqlalchemy. Во-вторых, это ведёт к усложнению, и растёт так называемая test matrix - потому что поддерживается как синхронный случай, так и асинхронный. А simple, как мы знаем, is better than complex.

Так вот, я решил возобновить свои попытки, изменив подход на более радикальный. А именно, необратимо переписать django на async-only, сломав совместимость полностью. Для этого потребуется в половине функций заменить def на async def и добавить await при их вызове. Я уверен, что такой подход лучше.

Не то, чтобы асинхронный django был очень кому-нибудь нужен, особенно теперь, или от этого будет какой-то фантастический выигрыш в производительности - дело в том, что я хочу попробовать на практике агентное программирование, а это, как раз подходящий проект: есть чёткий план и много кода, который нужно менять.

Мысль о том, что просто переписать всё на async/await - совсем не глупая идея, приходила мне в голову, ещё когда я работал над proof-of-concept-ом версии с гринлетами. Если нет совместимости - нет и проблем. Вот, например, версия с гринлетами поддерживала синхронный режим, но она чуть-чуть отличалась от самой django, и нужно было решать, в какой степени оставить между ними совместимость. Теперь же я считаю, что самая прямолинейная идея - переписать всё, без задней мысли о совместимости, и есть самая лучшая.

Те, кто читал мои предыдущии посты, наверное, в курсе - тем не менее, остановлюсь на первом важном аспекте: django часто функционирует "ленивым" образом, делая запросы в базу по мере необходимости. Например, при попытке узнать длину кверисета или при чтении некоторых атрибутов у объекта. Так вот - такое поведение действительно не совместимо с async/await, и поддерживать его не планируется. А планируется сделать все запросы в базу явными.

Явные запросы в базу

Кверисеты останутся ленивыми, но, чтобы их вычислить, нужно будет написать слово await:

await (qs := Book.objects.all())
print(len(qs))

Если не написать await, будет эксепшн. Второй способ, как можно вычислить кверисет - это асинхронная итерация:

qs = Book.objects.all()
async for book in qs:
  print(book.title)

Всё остальное, в том числе, доступ к атрибутам, к запросам в базу приводить не должно.

Например, пусть у нас есть объект book и у неё - атрибут author, на который он ссылается по внешнему ключу (Foreign Key). В этом случае, book.author должен нам вернуть автора, если мы его уже достали из базы (с помощью select_related или prefetch_related) или выбросить ошибку, если мы этого не сделали.

Кстати, в новой версии django уже сделали шаг в этом направлении: там можно указать fetch_mode(RAISE). В этом случае, связанные объекты не будут подтягиваться из базы автоматически. Это и есть как раз то поведение, которое нам нужно для асинхронного django.

Что касается так называемых свойств (вроде book.author), соответствующих связанным объектам, тут возникает ещё другой вопрос: что делать, если мы знаем, что ещё не достали из базы book.author, и хотим явно это сделать (только для данного объекта book). Я считаю, для этого должен быть какой-то отдельный способ (не доступ к атрибуту). Я предлагаю такой:

await book.get('author')

Deepseek, кстати, такой подход хвалит (ну, работа у него такая):

Последовательное выполнение

Предыдущий пункт про ленивые запросы будет единственным существенное отличием этого асинхронного форка от django. Остальное поведение менять не придётся - благодаря тому, что я собираюсь оставить парадигму последовательного выполнения. Это означает, что, несмотря на асинхронность, все операции, в рамках обработки одного запроса, мы всё равно будем выполнять последовательно, одну за другой. То есть, точно так же, как в обычном django. Даже никаких "fire and forget" не будет: если запускаем какую-то операцию, дожидаемся её завершения.

Всё это близко идее про виртуальные потоки из Java и Project Loom. У нас будет тоже что-то вроде виртуальных потоков. Вот, например, в django есть принцип "1 соединение с базой на 1 поток" - у нас будет 1 соединение на 1 "виртуальный поток". При таком подходе, даже поддержка сигналов не станет какой-то проблемой - все хендлеры будут выполняться один за другим.

Стоит отметить, что async/await - это единственная вещь, которую я планирую добавлять в рамках этого форка. Новых фич добавлять не планируется.

Тестирование

Важный вопрос - как это всё тестировать. Особенно если код будут писать агенты. Хорошо бы заюзать имеющиеся тесты django - их там несколько тысяч. И у меня есть план, как это сделать.

Во-первых, не обязательно сразу добавлять везде async и await. Первым делом, можно поменять парадигму с неявных запросов в базу на явные (как описано в п. 1) в имеющейся (блокирующей) версии. Потом - адаптировать тесты под это, убедиться, что они проходят.

Потом уже - добавить везде async/await. Но драйверы баз данных можно будет пока оставить прежние (блокирующие). В этом случае, реальной асинхронности не будет, и любую корутину можно будет выполнить, просто вызвав у неё next():

next(co.__await__())

То есть, например, можно будет написать декоратор pseudoasync, который будет превращать любую асинхронную функцию в обычную:

@pseudoasync
async def mytest():
  async for obj in Book.objects.all():
    print(book.pk)

Потом - можно будет снова запустить джанговскую test suite и добиться, чтобы тесты прошли.

И уже в самом конце - тестировать с асинхронным драйвером.

Статус

Статус у проекта, конечно, самый лучший: я ещё ничего не начинал. Собираюсь использовать Copilot или Claude. Нужно будет учиться работать циклами и в режиме планирования. Кстати, если кто-то хочет поработать над этим странным проектом в режиме парного программирования - напишите в л/с.

Имя у проекта осталось с прошлого раза - это vinyl. В целом, deepseek говорит, что всё придумано достаточно хитро и имеет шансы на успех. А вы что думаете?

Асинхронный django: новые начинания