Author chrysn
Recipients chrysn
Date 2011-01-07.00:32:52
SpamBayes Score 2.86185e-09
Marked as misclassified No
Message-id <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
In-reply-to
Content
The multiprocessing.manager.BaseManager class has a class property called _Server, defaulting to multiprocessing.manager.Server, that is used in the ._run_server method (typically invoked via .run()) to determine the class of the server that is to be created.

On the other hand, the .get_server() method creates an instance of Server independent of what is configured in ._Server. Thus, managers started via .run() behave slightly different than those started with .get_server().serve_forever(), and in a way that is hard to track.

I am aware that the ._Server property is undocumented, but it's quite useful when extending BaseManager in a way that it needs to be configured by the server.

I suggest to have .get_server() use ._Server instead of Server; I can't think of situations in which this does the wrong thing (rather, I assume that up to now, users of ._Server didn't try running with .get_server().serve_forever(); it seems ._Server is not used in the standard library).
History
Date User Action Args
2011-01-07 00:32:54chrysnsetrecipients: + chrysn
2011-01-07 00:32:54chrysnsetmessageid: <1294360374.53.0.588595674921.issue10850@psf.upfronthosting.co.za>
2011-01-07 00:32:52chrysnlinkissue10850 messages
2011-01-07 00:32:52chrysncreate