On Sat, 29 May 2010 08:28:46 am Vinay Sajip wrote:
I've not seen this mentioned, but on such a long thread I might have missed it: we already have a "__future__" module, as in
from __future__ import with_statement
and to my mind, this is a potential point of confusion with the term "future". [...] I'm not sure of the benefit of a "concurrent" namespace, since it wouldn't contain the existing concurrency stuff. I think it's something to consider only for a big reorg which would break backward compatibility. IMO it would make more sense to leave this module as a top-level module for now (a sibling to "threading", "multiprocessing").
I have suggested a way to move the existing concurrency stuff without breaking backwards compatibility, and Terry Reedy asked if it would work. I haven't seen any responses, either positive or negative. For the record, my suggestion was: for each concurrency modules: move it into the concurrency package add a top level module with the same name containing: # e.g. for threading from concurrency.threading import * Then in some future Python version, each top level module gets a PendingDeprecation warning, followed by a Deprecation warning some time later, and eventually in the indefinite future removal of the top level module. Leaving the futures module in the top level of the std lib is far more likely to confuse users than adding it to its own namespace. Compare: import __future__ import futures with: import __future__ import concurrency.futures In my opinion, it is high time for the std lib to pay more attention to the final Zen: Namespaces are one honking great idea -- let's do more of those! -- Steven D'Aprano