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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4