Комментарии 4
Почему в «async def handle_request» не используется асинхронный контекстный менеджер, это который аsync with. Он и откроет и закроет соединение после чтения.
В самом начале не понял, зачем асинхронность стоит у get на IndexView.
Ошибки или что улучшить в примерах:
В def push_all вместо распаковки генератора листа можно просто использовать генератор.
В _on_ping потерял долготу в блоке Else
Ну и я бы сделал сеттер геттер _coonections[_id] внутри которого сбрасывал бы счётчик таймаута. Иначе надо каждый раз писать второй строкой self._refresh_timeout(connection_id)
Привет! Спасибо за замечания, действительно, вы указали на не совсем явные моменты. Прокомментирую по пунктам:
1) Асинхронный контекстный менеджер осознанно не использовался, так как статья больше обучающая, а я по своему опыту изучения языка знаю, что контекстные менеджеры изначально немного пугают (может, конечно, только у меня такой опыт с ними) и скорее всего потребовалось бы отдельно про них рассказывать. Но использовать его конечно было бы удобнее и безопаснее
2) Асинхронность нужна, как минимум библиотеке aiohttp для работы - если перейти в source-код базового View, то там будет такие строчки:
method: Callable[[], Awaitable[StreamResponse]] = getattr(
self, self.request.method.lower(), None
)
resp = await method()
Но конечно это не главное - даже при передаче небольших html-файлов мы должны использовать асинхронность в асинхронном приложении. Если у нас будет медленный принимающий клиент, то даже передача нескольких сотен байт может заблокировать наш event loop на значительное время. Надеюсь я правильно интерпретировал смысл вашего комментария
3) Насчет генератора спорно - asyncio.gather принимает на вход список корутин, то есть генератор все-равно придется распаковать перед вызовом gather. Не могу сказать без измерений что эффективнее, но мне кажется, что разница должна быть не такой значительной
4) Да, действительно, поправлю
5) Геттеры и сеттеры тоже не слишком простая тема, но главной мотивацией для их не использования я бы назвал то, что нам не надо обновлять таймаут при записи в соединение, поэтому их применение кажется не совсем верным здесь
Еще раз спасибо вам за развернутый комментарий!
Приветствую и спасибо за статью! Недавно самому требовалось сделать на хакатоне приложение, в котом взаимодействуют пользователи друг с другом на питоне и с вебсокетами.
Но я просто решил использовать idom, и не погружаться в дебри вебсокетов... Теперь использую его для создания интерфейсов домашних проектов вместо QT
Websocket-сервер для геолокации на asyncio