On Fri, May 28, 2010 at 17:12, Steven D'Aprano <steve@pearwood.info> wrote:
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.
This was the procedure we used for about a month for Python 2.6 in order to help renamed modules migrate to their new names in Python 3. The issue that came up (and forced use to revert this approach and fully rely on 2to3) was anything pickled by the older interpreters is not going to be happy with that shift. Luckily the stuff being moved most likely does not contain things that have been pickled and stored to disk for ages and thus would break in a transition.