Twisted is a framework for writing asynchronous applications in Python.
So what does that mean?
It’s a different to how you’re used to writing things. If you’ve ever used a GUI toolkit, you probably have, though. Most GUIs use an event loop, just like Twisted.
However, if you’ve written a GUI, you’ve probably sidestepped that event loop by having your application run in a separate thread. When you’re writing Twisted-powered applications, you typically won’t be doing that.
Twisted supports a whole boatload of things, not necessarily limited to networking protocols. If you can’t find what you need in the Twisted API docs, try one of the following:
An asynchronous event loop is generally useful, but particularly well suited to applications that spend most of their time waiting. Two typical examples of these are:
- GUI apps
- Networking apps
Everyone writing GUI apps (like PyQt) is already writing asynchronously, even if they cheat by using threads. For networking apps, threading is still the predominant implementation.
Twisted lets you write them in a single thread, which makes debugging much less of a pain.
But all new processors have billions of cores, single threaded apps are terrible?!
Yes. No. Maybe.
Many people say “threading” when they mean “concurrency”, but here is a key difference: Threading isn’t the only concurrency model by far. In fact, it’s one of the more problematic ones. Threading has many problems.
Yes, most Twisted applications don’t do computational concurrency. For most applications that Twisted is a good idea for, that’s not really a big problem. For applications that need true concurrency, Twisted provides alternatives, such as Ampoule.
Because people tend to hear “don’t use threads, use Twisted” within one minute of each other, people mistakenly assume that writing programs asynchronously means that things can’t be evaluated in parallel. This is quite simply not true.
For a more in-depth explanation, read the Twisted asynchronous programmer tutorial