Смешанный асинхронный и синхронный код

А loop в соседний тред вынести нельзя? Sleep работает только по текущему треду. Плюс звучит да, криво, даже просто sleep уже криво

переписать все на asyncio тоже не хочется

Придётся.

У меня в одном проекте код смешанный, есть асинхронщина и обычный код

Не бывает смешанного кода, бывает асинхронный код, в котором блокирующие операции заворачивают в экзекуторы. Это или to_thread или run_in_executor.

asyncio.run:

This function always creates a new event loop and closes it at the end.

Не прокатит.

Sleep работает только по текущему треду.

А что, GIL уже отменили?

UPD: ага, прочитал доку, был неправ

Просто sleep не криво, там сервер за частые запросы банит по ip, sleep’ы нужны для обхода банов)

Оно итак в отдельном треде крутится…

Просто sleep не криво, там сервер за частые запросы банит по ip, sleep’ы нужны для обхода банов)

Не нужны здесь слипы, совсем не нужны. Меняйте архитектуру приложения или запускайте каждый запрос по планировщику синхронным кодом.

Да там обычный бесконечный цикл с запросами к серверу и ты предлагаешь вместо обычного слипа в конце заморочиться с шедулерами?

но sleep’ы приостанавливают работу

нет, конечно, оставляй.

Слипом наказывать запрос? 😄

Назло врагу уши морозите ))

PS: за слип в коде по рукам надо бить. Сильно бить. (У самого в одном проекте в тестах имеется, но я прям с отвращением писал ибо ограничен был по ресурсам и знал, что это времянка)

Ещё раз повторю. Бесконечный цикл запросов на сервер, в конце цикла добавить sleep 5 секунд никаких проблем не вижу. По рукам себя стукни ;-) Ну раз слип блокирует асинхронный код в треде другом, то придётся переделать, да.

Бесконечный цикл запросов на сервер, в конце цикла добавить sleep 5 секунд никаких проблем не вижу.

Ещё раз, запускай бесконечный цикл запросов с блокирующим io в отдельном потоке, оформляя через экзекутор или to_thread.

В документации всё есть - https://docs.python.org/3/library/asyncio-task.html#running-in-threads

import threading

Как раз через sleep можно частично контролировать gil и смену контекста. Аналогично через asyncio.sleep можно пропустить цикл без реального ожидания. Полезно когда есть нужно собрать результат пачки тасков но при этом нет возможности напрямую использовать скажем gather (например таски прикрыты толстым слоем 3rd party кода).

Делал такое для graphql для снятия проблемы N+1 при вложенных подзапросах - все запросы собираются путем пропуска одного цикла когда реальный запрос по сети уже отработал и остались только вызовы локальных обработчиков которые гарантированно завершатся в пределах цикла, а других вариантов связать запросы в кошках написанного на С фреймворка просто нету. Получается довольно короткое и красивое, хоть и несколько упоротое решение

Ок, а как тогда такое решение - заменить sleep в асинхронной части на ожидание эвента, и пулять эвент из синхронной?

Ну, тут если ты начал писать асинхронный код, то и все абстракции асинхронщины придётся использовать. Те весь код должен крутиться в асинк цикле самого движка, через вызов и создание абстракций. А ты спрашиваешь как не использовать абстракции и при этом взаимодействовать с кодом, который уже работает внутри этих абстракций. Это как через ж гланды выдирать. Всё переписывай или на свой асинк ио или лучше родной питонячий await async используй, он вполне тру для несложных вещей

Ты говоришь очевидные вещи, это итак понятно. Я просто хотел использовать в одном треде асинхронный евент луп :-) Вот такой код работает без проблем со слипами в основном треде.

    async def _run(self) -> None:
        self._pconnection.listen('notify_listing')
        self._exit = 1
        while True:
            if self._exit == 2:
                break
            self._handle_notify()
            await asyncio.sleep(1)

    def __call__(self, *args, **kwargs) -> None:
        loop: any = asyncio.new_event_loop()
        # loop.add_reader(self._pconnection.connection, self._handle_notify)
        loop.run_until_complete(self._run())

sleep в асинхронщине вообще не нужен так-то :-) sleep юзается в основном синхронном треде в бесконечном цикле.
Вон кусок сверх кинул.

заменить вызовы time.sleep на asyncio.run(asyncio.sleep(n)) это решит проблему и насколько это криво?

Нет. asyncio.run(asyncio.sleep(n)) создаст и запустит event-loop запихнув в него короутину asyncio.sleep(n). Когда короутина завершиться - тогда и завершиться event-loop. Как синхронный код стоял на этом месте, так он и будет стоять, только более высокотехнологическим способом)

От sleep’ов отказать не могу, переписать все на asyncio тоже не хочется)

А придется переписать на asyncio. Потому что асинхронную функцию (желанный тобой sleep) можно запускать и асинхронно дожидаться результата только из асинхронной функции.

В обычном коде присутствует множество time.sleep(n)

Ненависть!!!!

Я не настоящий погромист, но я бы на задачи, которые чего-то ждут с помощью sleep, наплодил бы threads, и асинхронно ждал бы результатов. Т.е. переписал бы. А как ты написал - порнография в самом плохом смысле.

GIL например на древнем отднопоиочном процессоре не имеет значения вообще, и вообще, это самая меньшая из проблем питона.

await asyncio.sleep(…)

И не надо ничего выдумывать

А если (не понимаю нахрена только) тебе так хочется вызывать не измазанный async/await код из асинхронного - используй to_thread, как праивльно уже сказали. И там слипы ничего не блокируют

Твоя реакция мне непонятна. Я исходил из посылки (да, оказавшейся ложной), что по time.sleep() тред спит, не отпуская GIL.

GIL например на древнем отднопоиочном процессоре не имеет значения вообще, и вообще, это самая меньшая из проблем питона.

Пошли обрадуем всех пользователей модуля multiprocessing, чего люди мучаются.

Ты сам написал что sleep у тебя по факту блокирует асинхронный код (должен блокировать) по окончанию цикла. Попробуй вместо того чтоб пытаться связать два треда (синхронный и тот где loop бегает) через sleep связать их через ожидание евента. Суть - ты все так же делаешь sleep в синхронный треде, а в асинхронном меняешь sleep на wait. Далее из синхронного треда по выходу из sleep делаешь event.set, запуская новый цикл

GIL например на древнем отднопоиочном процессоре не имеет значения вообще

Таки имеет, ты смешиваешь физические потоки, логические потоки ОС и потоки питона, это три разных вещи с разной логикой переключения

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

На cpu-bound да. На net io - нет. Gil как раз таки отпускает логический поток на io, а ос обычно имеет достаточно мозгов чтоб грамотно их переключать

Прокси + asyncio.sleep + про экзекуторы уже написали