我只是在搜索这个新实现，而且我使用 python 2.7，我必须安装this，所以如果我使用它，我会忘记 CPython 上的 GIL 这个词吗？
【问题讨论】：
future API 的 GreenThreadExecutor。 （然而，这有点棘手，这就是为什么 tulip 会为 stdlib 带来一个稍微不同的 future 以用于其协程事件循环。）
标签： python future gil concurrent.futures
不，concurrent.futures 与 GIL 几乎没有任何关系。
使用进程而不是线程是 GIL 的良药。 （当然，和所有药物一样，它也有副作用。但它有效。）
futures 模块只是为您提供了一种比直接使用threading 或multiprocessing 更简单的方法来安排和等待任务。它还有一个额外的优势，即您可以在线程池和进程池之间进行交换（甚至可能是一个 greenlet 循环，或者您发明和构建的一些疯狂的东西），而无需更改 future 代码。所以，如果你不知道你的代码会不会出现 GIL 问题，你可以构建它使用线程，然后通过一行更改将它切换为使用进程，这很不错。
但是，如果您使用ThreadPoolExecutor，它会出现与使用threading 和queue 手动创建线程池、任务队列等完全相同的 GIL 问题。如果您使用ProcessPoolExecutor，它将以与您手动使用multiprocessing 相同的方式（以及相同的权衡）避免 GIL 问题。
PyPI 包只是 concurrent.futures 模块从 3.2 到 2.x（和 3.0-3.1）的简单反向移植。 （它不会神奇地为您提供新的改进的 3.2 GIL，或改进程度更高的 3.3 GIL，更不用说删除 GIL。）
我什至不应该提到 GIL 的变化，因为这似乎只是增加了混乱……但现在，让我尝试通过过于简单化来理顺它。
如果您只有 IO 密集型工作，线程是获得并发性的好方法，达到合理的限制。并且 3.3 确实使它们工作得更好——但在大多数情况下，2.7 已经足够好，而对于大多数情况下，3.3 仍然不够好。如果您想同时处理 10000 个客户端，您将需要使用事件循环（例如，twisted、tornado、gevent、tulip 等）而不是线程。
如果您有任何 CPU 密集型工作，线程根本无助于并行化该工作。事实上，它们让事情变得更糟。 3.3 让这个点球没有那么糟糕，但它仍然是一个点球，你仍然不应该这样做。如果要并行化 CPU 工作，则必须使用进程，而不是线程。 3.3 的唯一优势是futures 比multiprocessing 更易于使用，并且是内置的，无需安装。
我不想阻止您迁移到 3.3，因为它比 2.7 更好地实现了更好的语言。但更好的并发性并不是改变的理由。
【讨论】：
concurrent.futures 确实没有解决任何问题，除了使并发代码更易于编写的问题。 3.2 和 3.3 中对 GIL 的更改是完全独立的，十多年来 GIL 的第一次重大更改与futures 库出现在同一版本的 Python 中只是巧合。
pip-3.3 install passlib，它工作正常。其次，在 2.7 上进行多处理的方式与在 3.3 上几乎完全相同。 multiprocessing 模块在 2.7 和 3.3 之间几乎相同，PyPI futures 反向端口与标准库中的 3.3 concurrent.futures 几乎相同。
passlib 可用于 3.3，您无需等待。它已经可用于 3.3。