On 26/05/10 23:01, Brian Quinlan wrote:
_thread, threading, Queue and multiprocessing do likely belong here,
but moving them isn't likely to be worth the pain. Does it help to
know that at least Jesse and I (and probably others) would like to see
concurrent.pool added eventually with robust general purpose
ThreadPool and ProcessPool implementations?
The specific reason the new package namespace was added was to help
avoid confusion with stock market futures without using an unduly
cumbersome module name, but I don't know how well the PEP explains that.
It doesn't at all. Are these plans formalized anywhere that I can link to?
Just the previous lot of discussions. The main point that should be
mentioned in the PEP is that "futures" on its own was ambiguous as to
the applicable domain, but "concurrent.futures" was perfectly clear,
without causing any readability problems the way a longer name could.
Moving the general purpose pools out to their own module was just an
example that occurred to us as something else that could go in that
package rather than a concrete plan for implementation.
Yes, we're setting ourselves up for inevitable questions as to why the
existing modules are top level rather than part of this package, but the
minimal pain response there would be to link to them from the package
documentation with a note along the lines of "for historical reasons,
some modules you might reasonably expect to find in this package are
instead provided as top level modules".
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---------------------------------------------------------------
_______________________________________________
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
