у тебя же на каждый такой вызов создастся фрейм

Ннннееее

он же себя вызывает только если при обработке конкретного реквеста прошлый итератор закончился

после обработки этого запроса он выходит назад в send_request

там глубина не больше двух

он же себя вызывает только если при обработке конкретного реквеста прошлый итератор закончился

он себя вызывает на каждое третье обращение к хэндлеру

все верно, отрабатывает его и выходит

и стек-то не реюзается, у тебя останется ссылка на родительский фрейм

на каждом вызове

не веришь - попробуй дерни код 3000 раз

упадет или нет?

уже 10 тыщ раз попробовал

он же выходит после обработки реквеста

народ, почему код: import os os.system("cat /path/to/file/file.txt|pbcopy") засовывает в буфер обмена в формате ascii??? файл utf-8... (macos & jupyter & python 2.7)

диспетчер завершает выполнение после отправки реквеста тем или иным способом

диспетчер завершает выполнение после отправки реквеста тем или иным способом

ну нет же, если он делает рекурсивный вызов

да он его обработал и вышел

у тебя фрейм остается висеть, чтобы интерпретатор знал, куда вернуть управление

так оно ж возвращатеся

сразу, условие идет по первой ветке, потому что ctx == None

так фрейм-то из памяти не собирается при этом gc

он остается висеть

да с чего бы вдруг то?

условие по первой ветке идет один раз

ок, ща 100 тыщ запущу )

да с чего бы вдруг то?

с того, что рекурсия так работает? :)

проверь recursionlimit на твоей системе

он из неё выходит на втором шаге

он из неё выходит на втором шаге

не выходит он, он делает рекурсивный вызов

у тебя остается в памяти висеть ненужная цепочка фреймов как минимум

короче, ты не прав, я уже 10 лямов запустил - все ок )

а как максимум - стековерфлоу

10 лямов - ок

не, я точно прав, просто, видимо, в случае генераторов оно чуть по-другому работает

проверь потребление памяти

растет ли оно

неа

запустил цикл в 100 миллионов

смотрю на память - ничего не меняется

процессор, естественно, 100%

странно

надо будет понять, где там оптимизация происходит

а, стоп, я понял

ты же присваиваешь ctx None

все

тогда да, неявность пропадает

первый вызов: send_request -> dispatcher -> handler() -> asend(None) второй вызов: send_request -> dispatcher -> asend(data) последний вызов: send_request - dispatcher - dispatcher - handler() - asend(None)

сразу не вкурил :)

да, все ок

но это магия адская, конечно

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

100 миллионов отработали нормально

ну, так-то да

но вообще код понять сложно поначалу)

магия там будет, когда я замучу это все в реальном диспетчере запросов. Там фильтры зарпосов всякие итд...

а откуда магическая константа 10?

из головы )

выполняю 10 запросов, я ж тестик написал, это не реальный код

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

а, это тест? понял

диспетчер один, он роутит запросы по хендлерам в зависимости от фильтров

сейчас не так, но так задумано в будущем

и вот теперь интересный вопрос...

в конкретный момент времени он один, да

а зачем тебе слипы в хэндлере?

чтобы видеть глазами как оно работает

ээ) ну окей

ERROR: S client not available

я ж так еще не делал никогда, вот 3.6 попробовал только что

так вот, вопрос следующий... как мне теперь отличать обычную корутину от асинхронного генератора?

обрабатывать то их надо совершенно по разному...

ты сейчас примерно так себя чувствуешь?

да да да да )))

так вот, вопрос следующий... как мне теперь отличать обычную корутину от асинхронного генератора?

никак?) асинхронный генератор - это та же корутина

ты сейчас примерно так себя чувствуешь?

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

никак?) асинхронный генератор - это та же корутина

а вот и нет!

я асинхронному генератору не могу сделать await

хм, там специальный вид эксепшена для этого?

мол, нельзя от двух вещей ждать - от бабы и от генератора?

обычный хендлер я вызываю так: await handler(data) а вот асинхронный генератор надо вызывать так: первый раз: gen = handler(data) await gen.asend(None) и в дальнейшем так: await gen.asend(data)

да я понял

то есть проматывать его извне

красота

но по нему же наверняка можно async for?

если yield не принимают значения?

конечно можно!

но это ж не мой случай, у меня задача другая

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

print(type(handler)) print(type(dispatcher)) <class 'function'> <class 'function'>

и для корутины и для генератора

что логично, ибо....

ибо генератор и корутина - это функции)

inspect.isasyncgen(), inspect.isasyncgenfunction()

inspect.isasyncgen(), inspect.isasyncgenfunction()

два чаю этому господину

но это будет адский код

. h = handler(0) d = dispatcher(0) print(type(h)) print(type(d)) <class 'async_generator'> <class 'coroutine'>

вот и решение )

А зачем так делать то, легаси какое-то?

А зачем так делать то, легаси какое-то?

У меня такая задумка старая есть - я хочу не покидая функцию обрабатывать несколько последовательных запросов, не теряя контекст. В реальности так: есть бот, у него есть wizard: пришли картинку, пришли название, пришли локацию. Сейчас это три отдельных хендлера, между которыми я передаю общий стейт, в конце каждого шага делаю ctx.set_next_handler(), а хочется заменить это одной функцией-генератором.