GeezerVison is showing github.com — [DISCUSSION] Support Python free threading / Make PTB thread safe · Issue #4873 · python-telegram-bot/python-telegram-bot
[DISCUSSION] Support Python free threading / Make PTB thread safe #4873DescriptionWhat kind of feature are you missing? Where do you notice a shortcoming of PTB?
With PEP 779 now accepted, we should think about making the library internals thread safe, specially for any user applications which involves spawning threads and then potentially interfacing with the library, e.g. via Application.
Why do we want to do this now?
It's because with free-threaded python, your threads will truly run in parallel, utilizing the extra CPU cores in your machine. This unlocks use cases where you can run CPU bound tasks and then do something with the result of that computation, like sending a message, or updating the persistence, or stopping the Application.
Mixing threading and concurrency is possible and not a problem as well. New threads require us to initialize a whole new event loop, and in that thread we can continue using async functions. Here's a blog article I found which shows the difference: https://blog.changs.co.uk/free-threaded-python-with-asyncio.html
Barebones PTB installation on free threaded Python
Running echobot.py with free threaded python works the last time I checked, but installing the optional dependency cryptography is not possible. Related issues: pyca/cryptography#12489 and python-cffi/cffi#178
Describe the solution you'd like
- Investigate what parts of the library need to be thread safe
- If some parts cannot be made thread safe, add a note in the documentation
- Add one test suite runner (3.14t on Linux?) which tests free threaded stuff, maybe using
pytest-run-parallel?
Describe alternatives you've considered
We can do nothing and keep advertising the warning of thread unsafety.
Additional context
I can't think of compelling use cases which would warrant making PTB thread safer, one use case would be running CPU bound tasks in threads, but the user can already set that up manually from jobs or callbacks. ActivityBibo-Joshi commented on Jul 27, 2025 Hi, thanks for the issue.
Having PEP 779 on the radar is indeed important. At the same time, I'd like to avoid premature optimization, especially as you already pointed out that we're not yet aware of any real use cases and (optional) dependencies are not yet ready for free-threading yet.
My take on this would be rather passive, i.e.
- discuss and implement improvements where actually use cases & limitations are reported, but don't actively search for them
- read through https://py-free-threading.github.io/ once to see if there are some obvious gotchas
- if setting up testing with https://github.com/Quansight-Labs/pytest-run-parallel is a relatively easy task and there are clear ideas of what should be tested with it, then I'm in favor for it. Just setting it up as bare minimum and the idea of "maybe it catches something" does not make much sense IMO. I'd then rather prever to set it up for testing specific findings once they are known
Would this approach make sense to you @harshil21 ? Poolitzer commented on Jul 27, 2025 Wont it already be an improvement to have our library be able to run on multiple cores? So the OS can throw it around however it feels like it?
If only crypto is an issue, which is only needed for payment api stuff, I feel like most bots wont be effected by this limitation. harshil21 commented on Aug 6, 2025
Would this approach make sense to you @harshil21
Yeah, specially since it's still early days and most of the python community is not used to doing things in threads because they were really nerfed (i.e. the GIL).
- use cases & limitations are reported, but don't actively search for them
One user request from the OT group about running multiple bots in the same script made me realize that this is a good use case for free threading. Or even running a web app bot, which has a PTB backend and maybe a flask/fast api/other library frontend.
I think the next step would be to try and run a few pure bots together in free threaded python to see what parts are (not) working. That way we can know which parts of the library we should test with pytest-run-parallel. Poolitzer commented on Aug 6, 2025 harshil21 commented on Oct 14, 2025 update: cryptography fully supports 3.14 free threading. I just ran the entire test suite locally on free threading with no failed tests.
What do you think of adding a 3.14t runner for the tests? This would be to just catch any new bugs so that we at least try to be free threading compatible. Bibo-Joshi commented on Oct 15, 2025 would be fine for me, yes :)
MetadataMetadataDevelopmentNo branches or pull requestsIssue actions |