Guido van Rossum wrote:
I consider multiprocessing a new API -- while it bears a superficial resemblance with the threading API the similarities are just that, and it should not be constrained by mistakes in that API.
The justification for including it is precisely that it is *not* a new API. For multiple processes in general, there are competing APIs, which may well be better. The advantage of this API is that (in many cases) it is a drop-in replacement for threading. If that breaks, then there really isn't any reason to include it in the stdlib yet. This doesn't prevent changing the joint API to conform with PEP 8. But why clean this module while leaving the rest of the stdlib? "Because there is a volunteer" only makes sense if changes to the other modules would also be welcomed. Is there some reason to believe that changes in the threading API are much less disruptive than changes elsewhere in the stdlib? -jJ