[Python-Dev] PEP 371: Additional Discussion
Guido van Rossum
guido at python.org
Wed Jun 4 01:21:10 CEST 2008
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.
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).
> Python-Dev mailing list
> Python-Dev at python.org
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev