On Sun, May 23, 2010 at 11:39, Brian Quinlan <br...@sweetapp.com> wrote: > This package eliminates the need to construct the boilerplate present in > many Python applications i.e. a thread or process pool, a work queue and > result queue. It also makes it easy to take an existing Python application > that executes (e.g. IO operations) in sequence and execute them in parallel. > It package provides common idioms for two existing modules i.e. > multiprocessing offers map functionality while threading doesn't. Those > idioms are well understood and already present in Java and C++.
It can do that as a separate package as well. And not only that, it could then be available on PyPI for earlier versions of Python as well, making it much more likely to gain widespread acceptance. > Could you be a little more specific about Guido's argument at PyCon? A module in stdlib has to be "dead". After it's included in the stdlib it can not go through any major changes since that would mean loss of backwards incompatibility. Also, you can't fix bugs except by releasing new versions of Python. Therefore the API must be completely stable, and the product virtually bugfree before it should be in stdlib. The best way of ensuring that is to release it as a separate module on PyPI, and let it stabilize for a couple of years. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 _______________________________________________ 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
