как правильно ждать?

Как по мне, это вообще плохая практика, как не крути. Лучше через jquery дергай статус.

jquery

python

WTF?

затем отдавать ответ на страницу

То есть ты задерживаешь ответ на запрос на неопределённое время? Это реально стрёмная практика. Просто отдавай ответ, что задача ещё не завершилась, а фронтенд пусть делает повторный запрос, пока задача не выполнится.

Подход достаточно старый, называется long polling.

Возможно для данного кейса лучше подойдёт брокер очередей.

Так может случиться ситуация, когда job.is_finished случится после таймаута запроса. Лучше сразу отдавать статус и пусть потом FE обрабатывает.

На стороне пользователя диалог с прогресс баром. В модальном режиме. Т.е. пользователь сделать ничего не может, пока задача не завершится. А как повторный запрос если используется диалог. Или на что тогда заменить этот диалог… Пример бы увидеть.

ответил не залогинившись.

Делаешь запрос на создание жобы, а потом, в случае нормального ответа, начинаешь как-то проверять статус другим запросом. Второе можно сделать миллионом способов: long polling, websocket или просто запросы по таймауту.

В flask нет нормальных решений если тебя не устраивает «заблокировать вот этот wsgi-воркер пока задача не выполнится». Ну, технически, можно накостылять с gevent и его monkeypatch, но это не нормальное решение.

Если устраивает — любое решение будет похоже на то, что у тебя в ОП-посте. Это не вебскейл, тебе нужно будет по отдельному процессу с flask’ом на каждого такого ждущего клиента и с какого-то момента оперативка внезапно кончится. Но если у тебя совсем низкая нагрузка (1 клиент?), то сойдёт.

Вариант решить в обход flask: rq-задача сохраняет результ, у тебя есть отдельный эндпойнт, который выдаёт либо результат, либо «спроси позже» клиенту без всяких time sleep. Типичный поллинг.

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

rq это уже очереди, пусть и совсем примитивные и прибитые гвоздями к redis.

Всем спасибо, кто не прошел мимо. Вроде дошло, что надо делать.

Для ожидания нужно принять позу лотоса. Повернуться в направлении Солнца. Руки расслабить и положить на бёдра ладонями вверх. Сложить большие и указательные пальцы. Убедится, что позвоночник ровный. Наблюдать за дыханием, но не контролировать его. Приступить к медитации на одной из 6 чакр на выбор, убедившись, что чакры расположенные ниже раскрыты. Если все 6 чакр раскрыты, то следует заняться оставшимися 106-тью. После чего можно переходить к последним – седьмой и 114-ой. Важно понимать, что при раскрытии 7-ой чакры положение дел с питоновским скриптом более не будет иметь значения. Вот так следует проводить ожидание. В качестве медитативной практики рекомендую следующие мантры. На вдохе мыслено произносишь «я не это тело», на выдохе – «я даже не этот разум». Не забывай следить за общей расслабленностью и прямотой позвоночника. Это всё, что я знаю о том, как проводить ожидание. Удачи.

почитай про celery

а он чем то координально отличается от rq? Ну кроме того, что один ‘worker’ может одновременно обрабатывать n количество задач.

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

Вообще можно gunicorn с gevent-воркером просто запустить, и всё будет типа ок. Ну пока в чей-нибудь таймаут не упрется.

Ииии? В чём вопрос? Или тебе есть разница, что будет отдавать ответ для jquery?

jquery

2020

Так, и? Может теперь ради каждого чиха обмазываться реактами, как и делает 99% альтернативно одаренных?

Откуда вы только беретесь, зумерки.

Там, где тебе не нужен реакт и другие высокоуровневые фреймворки, тебе не нужен и jquery, пиши на чистом js.