[issue3589] Misleading names for multiprocessing "convenience" functions

New submission from Nick Coghlan <[EMAIL PROTECTED]>: The package level imports from the new multiprocessing package exhibit some very strange behaviour because they are actually functions pretending to be classes: Python 2.6b1+ (trunk:64945, Jul 14 2008, 20:00:46) [GCC 4.1.3 20070929 (prereleas

[issue3589] Misleading names for multiprocessing "convenience" functions

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Setting to deferred blocker, since this really needs to be dealt with for RC1 (probably too close to b3 to get it discussed and dealt with for that). -- priority: critical -> deferred blocker ___ Pyt

[issue3589] Misleading names for multiprocessing "convenience" functions

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: > The delayed import functions in multiprocessing.__init__ look like a > serious misfeature to me. I'd be inclined to replace them with "from > .synchronize import *" and "from .process import *" +1 (or, even better, qualified than wildcard i

[issue3589] Misleading names for multiprocessing "convenience" functions

Changes by Barry A. Warsaw <[EMAIL PROTECTED]>: -- priority: deferred blocker -> release blocker ___ Python tracker <[EMAIL PROTECTED]> ___

[issue3589] Misleading names for multiprocessing "convenience" functions

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Patch attached that removes the misleading "convenience" functions, replacing them with explicit imports of the appropriate names. The patch also adds docstrings to some of the original class definitions that were missing them. No changes were

[issue3589] Misleading names for multiprocessing "convenience" functions

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Interesting - in some of the other work I was doing regarding the PEP 8 compliant alternative threading API, I noticed that the threading module contains similar gems such as: def Event(*args, **kwds): return _Event(*args, **kwds) Using a fa

[issue3589] Misleading names for multiprocessing "convenience" functions

Jesse Noller <[EMAIL PROTECTED]> added the comment: This is why multiprocessing had them nick - the threading module does On Sep 1, 2008, at 9:07 AM, Nick Coghlan <[EMAIL PROTECTED]> wrote: > > Nick Coghlan <[EMAIL PROTECTED]> added the comment: > > Interesting - in some of the other work I was

[issue3589] Misleading names for multiprocessing "convenience" functions

Changes by Jesse Noller <[EMAIL PROTECTED]>: -- keywords: +needs review -patch ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bug

[issue3589] Misleading names for multiprocessing "convenience" functions

Jesse Noller <[EMAIL PROTECTED]> added the comment: Patch reviewed/tested and I also confirmed that this doesn't affect the examples. I submitted the patch in r66114 -- resolution: -> fixed status: open -> closed ___ Python tracker <[EMAIL PROTECTED

[issue3589] Misleading names for multiprocessing "convenience" functions

Jesse Noller <[EMAIL PROTECTED]> added the comment: Reopening, there's a bug that the tests/examples/etc didn't catch (and nor did I), after the patch application: woot:python-trunk jesse$ ./python.exe Python 2.6b3+ (trunk:66112:66114M, Sep 1 2008, 13:00:19) [GCC 4.0.1 (Apple Inc. build 5484

[issue3589] Misleading names for multiprocessing "convenience" functions

Jesse Noller <[EMAIL PROTECTED]> added the comment: Ben is backing out the patch now ___ Python tracker <[EMAIL PROTECTED]> ___ ___ Python-bugs-l

[issue3589] Misleading names for multiprocessing "convenience" functions

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Given how long I've been using the threading module without realising it does the same thing, I'm actually prepared to live with the wrapper functions rather than messing with this so close to release. As Fredrik noted in the python-dev thread,

[issue3589] Misleading names for multiprocessing "convenience" functions

Benjamin Peterson <[EMAIL PROTECTED]> added the comment: Sounds good to me. :) -- nosy: +benjamin.peterson resolution: -> wont fix status: open -> closed ___ Python tracker <[EMAIL PROTECTED]> __

[issue3589] Misleading names for multiprocessing "convenience" functions

Antoine Pitrou <[EMAIL PROTECTED]> added the comment: Le lundi 01 septembre 2008 à 21:22 +, Nick Coghlan a écrit : > As Fredrik noted in the python-dev thread, the threading versions of > these are already explicitly documented as being factory functions > rather than classes (and as a refere

[issue3589] Misleading names for multiprocessing "convenience" functions

Nick Coghlan <[EMAIL PROTECTED]> added the comment: Not so much "too complicated" as "potentially touches a lot of code and not something I want to fiddle with this close to release". As I noted on python-dev, it's actually a change that can easily be handled through the normal API deprecation p