It would be useful to have the ability to run arbitrary code before a
manager's server subprocess is started (I'd use this feature to install
signal handlers for example).

here is a patch doing just that (against trunk).
ps: this is my first bug report and contribution to Python, please, be
gentle :)

Note that the Multiprocessing docs say that the Process "follows the API
of threading.Thread," and this would represent a (minor) divergence.

I also note that the patch does not contain any tests.

AFAIK there is no equivalent to the managers api in threading.
As for the tests, what kind of tests would you like to see? Jesse, some
thoughts on that?

Right, it's just the Thread/Process API equivalance.  I'm not saying
it's a stopper, but the docs would probably need to be modified accordingly.

As for tests, even just one that would prove that the method will be
called and do something trivial would be a good thing to have, IMO.

By the way, in case it isn't clear, I defer to Jesse on whether or not
it makes sense to accept this :)

I know, but tests (like the ones you outlined) would also make it more 
compelling

> Right, it's just the Thread/Process API equivalance.  I'm not saying
> it's a stopper, but the docs would probably need to be modified
> accordingly.
I'm a bit confused here. The patch only adds a small feature to
BaseManager and subtypes (the same way Pool does it already). AFAICT the
Thread/Process API equivalence is preserved. Am I missing something?

This patch should be better:
- checks that initializer is a callable, raise TypeError if not (do it
for Pool.__init__ also).
- adds tests for Pool.__init__ and SyncManager.start

The same against py3k.

Jesse, is there any chance that this will make it in, or should I just
go and implement a local solution?

On Mar 31, 2009, at 2:12 AM, lekma <report@bugs.python.org> wrote:

>
> lekma <lekmalek@gmail.com> added the comment:
>
> The same against py3k.
>
> Jesse, is there any chance that this will make it in, or should I just
> go and implement a local solution?
>

I'm thinking about it and plan on discussing it with other core devs  
today. Altering the Api is not something done lightly

> I'm thinking about it and plan on discussing it with other core devs  
> today. Altering the Api is not something done lightly
yep.
Thanks for considering it.

>I'm a bit confused here. The patch only adds a small feature to
>BaseManager and subtypes (the same way Pool does it already). AFAICT the
>Thread/Process API equivalence is preserved. Am I missing something?

No, I'm the one who was missing something.  I obviously didn't look at
the patch carefully enough.

committed in r71041 on python trunk, provided clean buildbots, we will 
merge to python 3.1

thanks guys