On Feb 26, 2010, at 5:49 AM, Jesse Noller wrote:
On Thu, Feb 25, 2010 at 12:27 PM, Jeffrey Yasskin
<jyass...@gmail.com> wrote:
... snip
In any case, I've updated the docs and PEP to indicate that
deadlocks are
possible.
Thanks. I still disagree, and think users are much more likely to be
surprised by occasional deadlocks due to cycles of executors than
they are
about guaranteed deadlocks from cycles of futures, but I don't want
to be
the only one holding up the PEP by insisting on this.
I think there are places the names could be improved, and Jesse
probably has
an opinion on exactly where this should go in the package
hierarchy, but I
think it will make a good addition to the standard library. Thanks
for
working on it!
Jeffrey
Yes; I think this needs to be part of a new "concurrent" package in
the stdlib - e.g. concurrent.futures, understanding things within
multiprocessing will be put in there shortly, and possibly other
things such as a threadpool and other common sugary abstractions.
Are you imagining that futures would be subpackage of concurrent with
a single logical namespace i.e.
concurrent/
__init__.py
futures/
__init__.py
threads.py
processes.py
...
from concurrent.future import wait
from concurrent.future import ThreadPoolExecutor
Or should the futures package be merged into the concurrent package i.e.
concurrent/
__init__.py
futures.py
threadpoolexecutor.py (was threads.py)
processpoolexecutor.py (as processes.py)
from concurrent.future import wait
from concurrent.future.threadpoolexecutor import ThreadPoolExecutor
?
Cheers,
Brian
_______________________________________________
stdlib-sig mailing list
stdlib-sig@python.org
http://mail.python.org/mailman/listinfo/stdlib-sig
