Honestly for python there's still one obvious way given just about all use-cases. Use multiprocessing for now. In the future a lot of stuff is going to shift o

Honestly for python there's still one obvious way given just about all use-cases. Use multiprocessing for now. In the future a lot of stuff is going to shift over to async-await. Until enough of your dependencies do it's fine if you ignore it for now. If you need any of the other options you'll probably already know and don't need to ask. Threading is good if you're doing a lot of waiting, but this use case is more or less replaced by async await. Multiprocessing is good multi-purpose. It works around the GIL and so works for most use cases. Async-await is like threading with a nicer programmer interface and works especially well for networking code and the like. The nice thing about async-await is that it's trivially interoperable with all the previous options. When using a framework or library that has an async-await API it'll be doing whichever form works best on the backside. E.g. awaiting a database query might spawn a thread or a process and you don't need to care. Subinterpreters are only relevant if you're writing C-code that embeds the python interpreter. So e.g. the mod_wsgi developers might care. A python developer never uses these directly. So unless you're a library author or doing fairly low-level things you won't need to care about any of the options but async-await pretty soon. The only awkward thing is that async-await isn't widely used/supported yet leading to there currently being two obvious ways to do it depending on what your libraries support. tl;dr; Use multiprocessing if you must. use async-await if you can. Let library developer worry about the tricky bits. Pretty soon just use async-await always.