Switch to asyncio

[Bibo-Joshi]

After some internal discussion we decided that it's time to make the switch to asyncio and we will do so in the next major release (v14). This is not due in the forseable future and this issue just summarizes some notes on that.

---

As this is a major breaking change, the community should be involved. What we do is:

• Make an announcement way ahead of release time & pin this issue
• Maintaining backward compatibility will probably be a lot of work and we already made the experience with use_context that this gives trouble. Therefore we will not offer a compatibility layer
• However, we should give the commutiy the chance to do so on their own. This will be achieved by making an announcement when the asyncio-branch is ready and giving the community some time to prepare before we actually release

---

Currently updates are handled one after the other by default and changing that would mean major breaking changes. Especially ConversationHandler usually relies on updates being processed one after the other. Noam sketched something how we could make dispatcher handle some updates asyncio and some sync. We should use that idea to make run_async basically work the same after the switch. We already have Defaults.run_async in place, so it's easy to make everything completely asynico if wanted.

Another rough thought in this direction: One could want updates to pass through the groups synchronously, while still processing multiple updates at the same time. We could add a setting for that and in Dispatcher do something like

if self.process_async:
    run_but_dont_await(self.process_update(update))
else:
    await self.process_update(update)

See here for some discussion.

---

Switching to asyncio will probably be a good time to switch to another lib for making requests. We can choose that work better with asyncio and doesn't need to be vendored. Candidates include

• httpx
• tornado+pycurl with the benefit that curl is the defacto standard (though latter would be a hassle for windows users)
• aiohttp. open question: does it support connection reusal? upside would be that users wouldn't have to install another lib for making requests, if they need that.

Requirements for a requests-lib to fulfill:

• connection reusal
• working behind proxies: http, socks5 + dns resolution over the proxy
• Would be great if it supports Google App Engine as urllib3 currently does

---

First feedback on the announcement included Flask not supporting asyncio natively. As Flask is one of the more common setups PTB is used in, we could provide an example on how to use asycnio PTB with flask.

Edit: We should probably still suggest to use a framework that supports asyncio natively, e.g. Quart

---

Check #2351 for more community feedback

[serjan-nasredin]

Yes! Good idea. I tried to rewrite, but I only made one commit ... and dropped it :)

[Poolitzer]

Regarding aiohttp, I had a quick glance through their docs and they definitly support it, keepalive flag is a parameter.

But there is aio-libs/aiohttp#2323...