[Python-Dev] PEP 8 vs PEP 371: Additional Discussion (original) (raw)

Guido van Rossum guido at python.org
Fri Jun 6 19:22:24 CEST 2008

On Thu, Jun 5, 2008 at 8:19 PM, Jim Jewett <jimjjewett at gmail.com> wrote:

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.

It is new in the stdlib. Insofar it is not new, renaming the methods is a very superficial thing.

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.

I've said before, and nobody has disagreed, that while familiarity with the threading module helps people understand how to use the multiprocessing module (as opposed to other APIs, which differ more deeply than just in their method names), but that I don't expect anyone to take an existing multi-threaded app of any complexity and turn it into a multi-processing app by changing one import.

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?

Have you actually read the thread? Many arguments were put forward for cleaning up the API -- there is no need to perpetuate mistakes of the past when introducing anything "new" to 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?

We'll keep the compatible API as long as needed. This means in 3.0 too.

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-Dev mailing list