Compatability with trio (alt async lib)

[brandyn]

Is there any interest in making this compatible with trio (https://trio.readthedocs.io/en/stable/)?

I find trio vastly cleaner than the default async libs, and my entire home-automation system is built on it.

I'm not sure how hard it is to make something compatible with both, but I've seen projects do it.

I currently use python-telegram-bot in trio via a background thread wrapper (ick, but it works). I haven't tried to use the async version (somewhat worried that, ironically, due to the upgrade to async, it will no longer work for me even though I've been using it async for years..).

[harshil21]

There is a wiki entry dedicated just for this: https://github.com/python-telegram-bot/python-telegram-bot/wiki/Frequently-requested-design-patterns#running-ptb-alongside-other-asyncio-frameworks

Hope it helps :)

[brandyn]

That seems to be for using other asyncio-based modules in the same asyncio application, whereas I'm wondering how hard it would be to make python-telegram-bot natively run on trio instead of asyncio at all (say, selectable via a configuration setting). If not, then people using trio would have to do something like this:

https://trio-asyncio.readthedocs.io/en/latest/usage.html

Which is pretty awful (looks like all the calls to the bot would have to be wrapped).

I haven't looked through the telegram async code enough to know how much of it is truly asyncio specific -- most normal async methods would be the same (including most awaits, etc), it's just the spawning and managing new tasks where they differ, plus whose version of things like sleep() you call. Depending on how the code is structured, it might just be a matter of replacing the asyncio specific calls with generics that perform equivalent tasks via asyncio or trio depending on the config. On the other extreme, if it relies heavily on any aspect where the asyncio and trio paradigms markedly differ, it might not be possible without a full code refactor.

When I get the time, I will look over the async version and see. If anyone else is interested in this, please chime in.

[Bibo-Joshi]

Hi. Thanks for reaching out.

TBH I've never worked with trio before and I'm not really familiar with the differences between trio and asyncio. So let me start with a more general note: PTB tries rather hard to be as dependency-free as possible. Currently the only required 3rd party dependency is httpx for the networking backend. There are several components in PTB that do require other 3rd party dependencies, both those components are all opt-in and hence the dependencies are installed via extra requirements (e.g. pip install python-telegram-bot[job-queue]). This comes at the cost of adding some code that checks if the dependencies are there (and also unit-testing that), but the effort is not too bad for the most part, as the 3rd party dependencies are used in only very few places.

Adding a 3rd party dependency for the concurrency logic would systematically be rather different, as we use the concurrency basically throughouth the whole library. If one would decide to make this dependency an optional depndency as well, this would e.g. mean that we have to run the whole test-suite twice.

Now a bit more in the direction of trio/effort to reimplement. I dare say that PTB does not use much of hacky lowlevel asyncio stuff. I searched through our lib and the functionality that we use currently is:

asyncio.{

• Lock
• Queue
• Event
• gather
• sleep
• BoundedSemaphore
• Task
• create_task
• gather
• get_event_loop
• CancelledError
• TimeoutError
• wait_for
• iscoroutinefuntction
• shield
  }

loop.{

• run_until_complete
• loop.stop
• loo.run_forever
  }

AFAIK, managing tasks is handled somewhat different in trio, where they use the nurseries. IIRC a similar concept has also been introduced in py3.10/3.11. For the telegram package, I imagine that the transition-effort is relatively small. For telegram.ext it might be a bit bigger, especially Application and Updater make more extensive use of tasks & cancellation.

@brandyn if you gain more insights on this, please let us know.

If one aims for supporting trio, I personally see two options in terms of dependencies:

• If we want to make it an optional dependency, the dependency should be trio and we write our own compatibility-module. This probably means that we don't make use of the big selling points of trio.
• If we're okay with a required dependency, IMO it should be anyio. That way we won't have to write our own compatibility layer and alsos don't have to test everything twice. Making anyio an optional dependency doesn't make much senes IMO, as that would mean writing a compatibility layer for a compibility library …

So far, this thread is the first request for support of a non-asyncio library (next to trio, there's also curio and twisted, both not supported by anyio). As the effort to support trio is probably not trivial, I'm not overly enthusiastic to get started right away, tbh. I would suggest that we handle this simlarly to #3355 for now, i.e. we open a feature-request issue that's not on any roadmap and wait to see if there's a critical mass of users who would like to have this feature. If there is, we can still discuss how we want to handle the additional dependencies.

Let me cc the other dev-team members to see if they have additional comments:
@Poolitzer @harshil21 @lemontree210 @clot27

[lemontree210]

I agree that

• our main aim should be keeping 3rd-party dependencies to a minimum
• if we introduce something new it should probably be anyio

I'm saying all this from a general perspective, since I haven't worked with trio either.

[brandyn]

Hi, thanks for the in-depth consideration!

"a similar concept has also been introduced in py3.10/3.11"

This raises the prospect that if we just wait long enough, asyncio will become trio and trio will become obsolete. I can easily imagine this happening because, imo, trio got it right. (Annoying for me because it means I'll have to port all my stuff back from trio, but oh well.)

"For the telegram package, I imagine that the transition-effort is relatively small. For telegram.ext it might be a bit bigger"

That was my impression looking through the code as well. I am not using telegram-ext personally, so would be quite happy to see trio supported in telegram only, but I realize that would be even more niche of a feature request than it already is.

I will probably just keep using an older version of the library for now. If I find myself needing newer telegram features, I guess I'll upgrade to the async version and attempt to make it run in trio and will submit my changes if I succeed.

"open a feature-request issue that's not on any roadmap"

(If so, let me know, thanks!)

[Bibo-Joshi]

"a similar concept has also been introduced in py3.10/3.11"

This raises the prospect that if we just wait long enough, asyncio will become trio and trio will become obsolete. I can easily imagine this happening because, imo, trio got it right. (Annoying for me because it means I'll have to port all my stuff back from trio, but oh well.)

Adding a reference here for completeness: https://docs.python.org/3/whatsnew/3.11.html#asyncio
Note that PTB usually supports Python versions until they reach EOL, so we'll probably be able to use new features of python 3.11 only starting in 2026-10.

"For the telegram package, I imagine that the transition-effort is relatively small. For telegram.ext it might be a bit bigger"

That was my impression looking through the code as well. I am not using telegram-ext personally, so would be quite happy to see trio supported in telegram only, but I realize that would be even more niche of a feature request than it already is.

True that :D

[brandyn]

After researching this all a bit more, anyio does seem to be the way to go. The direct advantage for PTB would be simply that anyio provides a cleaner (safer, easier, simpler) structured async model. I.e., it may be worth the effort to "port" PTB fully to anyio just to make it easier to develop and maintain going forward. A side effect is that PTB would also work in trio projects.