对我来说，这实际上很简单：
该子选项：
subprocess是用于运行其他可执行文件 ---它基本上是一个包装器os.fork()，并os.execve()带有可选的管道一定的支撑（管道设置，并从子进程。很明显，你可能其他进程间通信（IPC）机制，如插座，或POSIX或SysV共享内存，但是您将受限于所调用程序所支持的任何接口和IPC通道。
通常，任何人都可以subprocess同步使用---只需调用某个外部实用程序并回读其输出或等待其完成（也许从一个临时文件中读取结果，或者将其发布到某个数据库中）即可。
但是，可以产生数百个子流程并对其进行轮询。我自己个人最喜欢的实用程序classh正是这样做的。
最大的缺点了的subprocess模块是I / O支持通常是封锁。有一个PEP-3145草案可以在将来的Python 3.x版本和一个替代的asyncproc中进行修复（警告会导致直接下载，而不是任何文档或自述文件）。我还发现，直接导入fcntl和操作PopenPIPE文件描述符相对容易---尽管我不知道它是否可以移植到非UNIX平台。
（更新：2019年8月7日：Python 3支持ayncio子流程：asyncio子流程）
subprocess 几乎没有事件处理支持 ... 尽管您可以使用signal模块和普通的老式UNIX / Linux信号-像以前那样轻柔地杀死进程。
在多处理选项：
multiprocessing是对现有的（Python）的代码中运行的功能，可支持这个家庭的过程中更加灵活的通信。特别是，最好在可能的情况下multiprocessing围绕模块的Queue对象构建IPC ，但您也可以使用Event对象和各种其他功能（其中一些功能大概mmap是在足够支持的平台上围绕支持构建的）。
Python的multiprocessing模块旨在提供与接口和功能非常相似的 功能，threading同时允许CPython在具有GIL（全局解释器锁定）的情况下在多个CPU /内核之间扩展您的处理。它利用了由OS内核开发人员完成的所有细粒度SMP锁定和一致性工作。
该线程选项：
threading适用于受I / O限制（不需要跨多个CPU内核扩展）的相当狭窄的应用程序范围，并且受益于线程切换（带有共享核心内存）与进程/上下文切换。在Linux上，这几乎是空集（Linux进程切换时间非常接近其线程切换时间）。
threading在Python中有两个主要缺点。
当然，其中之一是特定于实现的-主要影响CPython。那就是GIL。在大多数情况下，大多数CPython程序不会受益于两个以上CPU（内核）的可用性，并且性能通常会受到 GIL锁定争用的影响。
与实现无关的更大问题是线程共享相同的内存，信号处理程序，文件描述符和某些其他OS资源。因此，程序员必须非常小心对象锁定，异常处理以及其代码的其他方面，这些方面都很微妙，并且可能杀死，停止或死锁整个进程（线程套件）。
通过比较，该multiprocessing模型为每个进程提供了自己的内存，文件描述符等。其中任何一个崩溃或未处理的异常只会杀死该资源，而可靠地处理子进程或同级进程的消失比调试，隔离要容易得多。并修复或解决线程中的类似问题。
- （请注意：
threading与主要的Python系统（例如NumPy）一起使用，可能比大多数自己的Python代码所遭受的GIL竞争要少得多。这是因为它们是专门为这样做而设计的； NumPy的本机/二进制部分，例如，在安全的情况下会释放GIL）。
在扭曲的选项：
还值得注意的是，Twisted提供了另一种选择，既优雅又难以理解。基本上，在过度简化的风险下，Twisted的粉丝可能会用干草叉和火把冲进我的家，Twisted在任何（单个）过程中提供事件驱动的协作式多任务处理。
要了解这是如何实现的，应该阅读一下select()（可以围绕select（）或poll（）或类似的OS系统调用构建）的功能。基本上，所有这些都由以下能力驱动：操作系统请求进入睡眠状态，以等待文件描述符列表中的任何活动或某个超时。
从这些调用中的每一个唤醒，select()都是一个事件---要么涉及一些套接字或文件描述符上的可用输入（可读），要么涉及某些其他（可写）描述符或套接字上可用的缓冲空间，以及一些特殊情况（TCP）带外推送数据包）或超时。
因此，Twisted编程模型是围绕处理这些事件然后在生成的“主”处理程序上循环构建的，从而使其可以将事件分派给您的处理程序。
我个人认为Twisted是编程模型的代名词，因为从某种意义上讲，解决问题的方法必须“内卷”。您不是将程序视为对输入数据，输出或结果的一系列操作，而是将程序编写为服务或守护程序，并定义程序对各种事件的反应。（实际上，Twisted程序的核心“主循环”是（通常？总是？）a reactor()）。
使用Twisted的主要挑战包括围绕事件驱动的模型扭曲思维，并避免使用任何未经编写在Twisted框架内合作的类库或工具包。这就是为什么Twisted提供了自己的模块来进行SSH协议处理，curses，自己的子进程/ Popen函数以及许多其他模块和协议处理程序的原因，这些模块和协议处理程序乍看起来似乎在Python标准库中是重复的。
我认为从概念上理解Twisted很有用，即使您从不打算使用它。它可以提供有关线程，多处理甚至子流程处理以及您执行的任何分布式处理中的性能，争用和事件处理的真知灼见。
（注意：较新版本的Python 3.x包含asyncio（异步I / O）功能，例如async def，@ async.coroutine装饰器和await关键字，以及从将来的支持中产生的收益。所有这些都大致类似于从流程（合作多任务）的角度来看是扭曲的。（有关Twisted对Python 3的支持的当前状态，请查看：https : //twistedmatrix.com/documents/current/core/howto/python3.html）
该分布选项：
您尚未询问的另一个处理领域，但值得考虑的是分布式处理。有许多用于分布式处理和并行计算的Python工具和框架。我个人认为，最容易使用的是在该空间中最不常用的一种。
围绕Redis构建分布式处理几乎是微不足道的。整个密钥存储区可用于存储工作单位和结果，Redis LIST可用作Queue()类似的对象，而PUB / SUB支持可用于类似Event的处理。您可以散列密钥并使用在Redis实例的松散集群中复制的键来存储拓扑和散列令牌映射，以提供一致的散列和故障转移，以扩展到超出任何单个实例的容量来协调工作人员并在其中封送数据（腌制，JSON，BSON或YAML）。
当然，当您开始围绕Redis构建更大规模，更复杂的解决方案时，您正在重新实现已经使用Celery，Apache Spark和Hadoop，Zookeeper，etcd，Cassandra等解决的许多功能。这些都具有用于Python访问其服务的模块。
[更新：如果您考虑将Python用于分布式系统中的计算密集型，则需要考虑以下两个资源：IPython Parallel和PySpark。尽管这些是通用分布式计算系统，但它们尤其是可访问且流行的子系统，即数据科学和分析]。
结论
从单线程，简单的同步调用到子进程，轮询的子进程池，线程和多处理，事件驱动的协作式多任务处理以及分布式处理，到处都有Python的处理替代方案。