Update from Brian Quinlan that "adds a section explaining the rational of

naming the package concurrent.futures."

pep-3148.txt

@@ -33,14 +33,35 @@ when each component invents its own parallel execution strategy.
 Specification
 =============
 
+Naming
+------
+
+The proposed package would be called "futures" and would live in a new
+"concurrent" top-level package. The rationale behind pushing the
+futures library into a "concurrent" namespace has multiple components.
+The first, most simple one is to prevent any and all confusion with
+the existing "from __future__ import x" idiom which has been in use
+for a long time within Python. Additionally, it is felt that adding
+the "concurrent" precursor to the name fully denotes what the library
+is related to - namely concurrency - this should clear up any addition
+ambiguity as it has been noted that not everyone in the community is
+familiar with Java Futures, or the Futures term except as it relates
+to the US stock market.
+
+Finally; we are carving out a new namespace for the standard library -
+obviously named "concurrent". In this namespace we hope to either add,
+or move existing, concurrency-related libraries to this in the future.
+A prime example is the multiprocessing.Pool work, as well as other
+"addons" included in that module, which work across thread, and
+process boundaries.
+
 Interface
 ---------
 
-The proposed package would be called "futures" and would live in a new
-"concurrent" top-level package. It provides two core classes: `Executor` and
-`Future`. An `Executor` receives asynchronous work requests (in terms of a
-callable and its arguments) and returns a `Future` to represent the execution
-of that work request.
+The proposed package provides two core classes: `Executor` and
+`Future`. An `Executor` receives asynchronous work requests (in terms
+of a callable and its arguments) and returns a `Future` to represent
+the execution of that work request.
 
 Executor
 ''''''''