[Python-Dev] PEP 3148 ready for pronouncement

[Jesse Noller]

On May 28, 2010, at 8:12 PM, 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.
>
>
> 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!
>
>
>
Yes, your suggestion for how to move things is the way we would want  
to do it, and in the back of my head, what we should do long term -  
just not right now.