[Python-Dev] PEP 371: Additional Discussion

[Raymond Hettinger]

I think its a small disaster to have the APIs be almost
 the same but with trivial differences in spelling.

PEP 8 is a nice guideline but it seems to have become
an end in an of itself.  The point of the PEP is to use
consistency as a memory cue, but having two sets of
method names that are almost parallel but spelled
differently is at odds with that goal.

Moving both modules to PEP 8 compliance makes more
sense, but I would hope that gets left for Py3.0.  There's
too much existing code, too many existing tutorials, and
too many hardcopy books already in Py2.x.


Raymond


----- Original Message ----- 
From: "Guido van Rossum" <guido at python.org>
To: "Mike Klaas" <mike.klaas at gmail.com>
Cc: <python-dev at python.org>
Sent: Tuesday, June 03, 2008 4:21 PM
Subject: Re: [Python-Dev] PEP 371: Additional Discussion


I'm curious why people thing that strict API compatibility is
important at all. In my view, having the APIs be similar is really
helpful because it helps people quickly understand what you can do
with the new module. But I honestly don't expect anyone to take an
existing app using threading and turning it into one using
multiprocessing by changing a single line. There are too many things
that threads let you do that aren't supported by processes (e.g.
shared mutable objects protected by locks).

IMO the multiprocessing module should only provide a PEP-8-compliant
API, and optionally we could start adding such an API to the threading
module. Strict compatibility with the Java API really isn't important
there either -- that's just how I got started with it, and I gladly
admit I went overboard there.

--Guido

On Tue, Jun 3, 2008 at 4:01 PM, Mike Klaas <mike.klaas at gmail.com> wrote:
>
> On 3-Jun-08, at 3:53 PM, Benjamin Peterson wrote:
>
>> On Tue, Jun 3, 2008 at 5:08 PM, Jesse Noller <jnoller at gmail.com> wrote:
>>>
>>> Also - we could leave in stubs to match the threading api - Guido, David
>>> Goodger and others really prefer not to continue the "broken" API of the
>>> threading API
>>
>> I agree that the threading the the pyprocessing APIs should be PEP 8
>> compliant, but I think 2 APIs is almost worse than one wrong one.
>
> A cleaner way to effectuate the transition would be to leave the camelCase
> API in 2.6 (for both modules), switch to PEP 8 in py3k (for both modules),
> and provide threading3k and multiprocessing3k modules in 2.6 that façade the
> 2.6 API with the PEP 8 API.
>
> 2to3 would rewrite 'import threading3k' to 'import threading' and everything
> would work (it would warn about 'import threading' in 2.6 code).
>
> -Mike
> _______________________________________________
> Python-Dev mailing list
> Python-Dev at python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>



-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
_______________________________________________
Python-Dev mailing list
Python-Dev at python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com