N
так что проще использовать ensure_future чаще и не париться
Size: a a a
2017 October 21
СК
Спасибо большое всем!
СК
Хорошо 👍🙈
AO
для того, чтобы дергать явно create_task - надо явно передавать везде объект лупа. От этого подхода отказались в питоне 3.6+
Откуда такая информация и кто именно отказался? )
N
Откуда такая информация и кто именно отказался? )
N
Там было много неявной магии, и ребята починили в 3.6, чтобы asyncio.get_event_loop() всегда давал текущий луп. Что позволило не париться о том, чтобы его явно везде передавать, как рекомендовалось делать ранее
СК
А ситуации когда у тебя несколько лупов по идее не должно быть. Ну смысла я не вижу в нескольких лупах
AO
Там было много неявной магии, и ребята починили в 3.6, чтобы asyncio.get_event_loop() всегда давал текущий луп. Что позволило не париться о том, чтобы его явно везде передавать, как рекомендовалось делать ранее
I think there's a whole new recommendation for library authors. They should just rely on get_event_loop() except under two circumstances:
- When you need a loop but your loop is not yet running. Note that this should be very rare -- e.g. when you're calling a coroutine function like asyncio.sleep() and passing it to another loop (or to run_until_complete()) you do *not* need the loop because the body of the coroutine doesn't start running until it is first scheduled.
- When run inside an application, framework or test that explicitly sets the global event loop to None. This should only be a backwards compatibility concern at this point: we should recommend that such apps, frameworks and tests switch to allowing get_event_loop(), *unless* they are bound to backward requirement with the stdlib asyncio in Python 3.4 or 3.5.3 (or old asyncio installations on 3.3).
--Guido
- When you need a loop but your loop is not yet running. Note that this should be very rare -- e.g. when you're calling a coroutine function like asyncio.sleep() and passing it to another loop (or to run_until_complete()) you do *not* need the loop because the body of the coroutine doesn't start running until it is first scheduled.
- When run inside an application, framework or test that explicitly sets the global event loop to None. This should only be a backwards compatibility concern at this point: we should recommend that such apps, frameworks and tests switch to allowing get_event_loop(), *unless* they are bound to backward requirement with the stdlib asyncio in Python 3.4 or 3.5.3 (or old asyncio installations on 3.3).
--Guido
AO
если app будет гарантировано работать на >= 3.6 то можно доверять get_event_loop()
AS
3.5.3+ если быть точным
AO
3.5.3+ если быть точным
да )
N
А ситуации когда у тебя несколько лупов по идее не должно быть. Ну смысла я не вижу в нескольких лупах
Если у тебя комбинация тредов и asyncio - то будет несколько
N
3.5.3+ если быть точным
Я немного радикален в этом :) мне кажется, что если человек в 2017 году стартует проект на питоне <3.5 - он ССЗБ
СК
Если у тебя комбинация тредов и asyncio - то будет несколько
Спасибо большое
СК
То есть если у меня обычное wsgi приложение то в каждом потоке будет свой луп? Я же могу общий использовать и тогда get_event_lopp будет давать один и тот же луп
AS
Если обычное wsgi -- забудьте про asyncio. Эти миры не пересекаются.
СК
Почему? Я же могу запустить допусти 1к http запросов в текущем потоке вместо создания потоков
AS
@Nikolay какая версия Python в последнем Debian?
AS
Нет, толку -- ноль. 1к запросов будет занимать непозволительно большое время, хоть последовательно хоть параллельно. За сколько милисекунд вы должны давать HTTP ответ? Несопоставимые времена
AT
@asvetlov ip-172-31-29-143:~# python3 -V
Python 3.5.3
Python 3.5.3