[Python-Dev] PEP 3148 ready for pronouncement

[Brett Cannon]

On Fri, May 28, 2010 at 17:12, Steven D'Aprano <steve at 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.