What 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.