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

Guido van Rossum guido at python.org
Wed Jun 4 06:36:34 CEST 2008

On Tue, Jun 3, 2008 at 6:48 PM, Raymond Hettinger <python at rcn.com> wrote:

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

Strong words -- and it now seems just your gut feelings against mine. I have come to trust mine quite a bit.

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.

PEP 8 helps by making exact method spellings easier to remember. The recommendation against abbreviations also comes from this goal. It should be used for all new APIs. (Except of course when adding to a set of existing APIs that use a different convention.)

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.

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.

It was decided not to "fix" APIs for Py3k beyond the module naming issue. We can add a new PEP-8-compliant API to the threading module in 3.0 but the old API should stay for another release or more. I'm neutral on whether it makes sense to backport the new threading.py APIs to 2.6.

--Guido

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

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

More information about the Python-Dev mailing list