This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: inconsistent behavior concerning multiprocessing.manager.BaseManager._Server
Type: behavior Stage: patch review
Components: Extension Modules Versions: Python 3.11, Python 3.10, Python 3.9, Python 3.8
process
Status: open Resolution:
Dependencies: Superseder:
Assigned To: sbt Nosy List: asksol, bar.harel, berker.peksag, chrysn, davin, jnoller, ppperry, sbt
Priority: normal Keywords: easy, patch

Created on 2011-01-07 00:32 by chrysn, last changed 2022-04-11 14:57 by admin.

Pull Requests
URL Status Linked Edit
PR 30086 open bar.harel, 2021-12-13 11:59
Messages (4)
msg125606 - (view) Author: chrysn (chrysn) * Date: 2011-01-07 00:32
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).
msg220889 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2014-06-17 20:59
Can we have a response to this please.
msg264609 - (view) Author: (ppperry) Date: 2016-05-01 21:18
You're working with non-documented internal components of the python standard library with names that start with an underscore. I think that this is not a bug in python, but instead a consequence of mucking with internals that weren't designed to be mucked with.
msg408081 - (view) Author: Bar Harel (bar.harel) * Date: 2021-12-09 08:03
It's technically not a bug as it is not exposed externally, but I concur with the OP that it shouldn't happen. I'll send a fix either way, and from there we will continue asking if _Server should be exposed or not.
History
Date User Action Args
2022-04-11 14:57:10adminsetgithub: 55059
2021-12-13 11:59:59bar.harelsetkeywords: + patch
stage: needs patch -> patch review
pull_requests: + pull_request28307
2021-12-09 08:03:33bar.harelsetnosy: + bar.harel

messages: + msg408081
versions: + Python 3.8, Python 3.9, Python 3.10, Python 3.11, - Python 2.7, Python 3.5, Python 3.6
2016-05-01 21:18:25ppperrysetnosy: + ppperry
messages: + msg264609
2016-04-29 20:43:13BreamoreBoysetnosy: - BreamoreBoy
2016-04-29 10:40:56berker.peksagsetkeywords: + easy
nosy: + berker.peksag, davin
stage: needs patch

versions: + Python 3.6, - Python 3.4
2014-06-28 17:47:31sbtsetassignee: sbt
2014-06-17 20:59:22BreamoreBoysetversions: + Python 2.7, Python 3.4, Python 3.5, - Python 3.2
nosy: + BreamoreBoy, sbt

messages: + msg220889

components: + Extension Modules, - None
2011-01-08 05:38:27ned.deilysetnosy: + asksol, jnoller
2011-01-07 00:32:52chrysncreate