On May 23, 2010, at 7:15 PM, geremy condra wrote:
On Sun, May 23, 2010 at 2:37 AM, Brian Quinlan <br...@sweetapp.com>
wrote:
<snip>
Finally, why isn't this just a module on PyPI? It doesn't seem
like there's
any particular benefit to making this a stdlib module and going
through the
whole PEP process - except maybe to prompt feedback like this :).
We've already had this discussion before. Could you explain why
this module
should *not* be in the stdlib e.g. does it have significantly less
utility
than other modules in stdlib? Is it significantly higher risk? etc?
Inclusion in the stdlib is the exception, not the rule, and every
exception should be issued for a good reason. I'd like to know
what that reason is in this case,
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++.
if only to get a clearer
understanding of why the PEP was accepted.
It hasn't been accepted.
Issues like the ones I'm bringing up could be fixed pretty
straightforwardly
if it were just a matter of filing a bug on a small package, but
fixing a
stdlib module is a major undertaking.
True but I don't think that is a convincing argument. A subset of the
functionality provided by this module is already available in Java
and C++
and (at least in Java) it is used extensively and without too much
trouble.
If there are implementation bugs then we can fix them just like we
would
with any other module.
Guido made exactly the opposite argument during his keynote at PyCon.
It seemed fairly reasonable at the time- why do you think it doesn't
apply
here?
Could you be a little more specific about Guido's argument at PyCon?
Cheers,
Brian
_______________________________________________
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
