[Python-Dev] PEP 8 vs PEP 371: Additional Discussion

[Guido van Rossum]

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/)