On May 28, 2010, at 8:12 PM, Steven D'Aprano <st...@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.
_______________________________________________
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
