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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
