[issue40307] multiprocessing.BaseManager does not retain Client type.
Change by Alessandro Molina : -- keywords: +patch pull_requests: +18942 stage: -> patch review pull_request: https://github.com/python/cpython/pull/19609 ___ Python tracker <https://bugs.python.org/issue40307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40307] multiprocessing.BaseManager does not retain Client type.
Alessandro Molina added the comment: The issue seems fairly easy to fix, it's just a matter in consistency in usage of self._Client attribute in the manager. I'm working on a PR that I'm willing to propose for review once I have finished it and wrote tests. -- ___ Python tracker <https://bugs.python.org/issue40307> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40307] multiprocessing.BaseManager does not retain Client type.
New submission from Alessandro Molina :
When a new `multiprocessing.managers.BaseManager` instance is made, the client
used to connect is not stable across the life of the object.
A very quick example to show that is
```
from unittest.mock import Mock
from multiprocessing.managers import SyncManager, listener_client
listener_client["faked"] = listener_client["xmlrpclib"]
sm = SyncManager(serializer="faked")
```
As expected the manager is created with the XmlClient
```
>>> print(sm._Client.__name__)
XmlClient
```
but in reality, if the "faked" serializer is changed in any way
```
listener_client["faked"] = (None, Mock(side_effect=RuntimeError("BROKEN")))
```
When trying to connect, we will unexpectedly connect with whatever it is the
serializer registered at the time of connection instead of the one bound to the
SyncManager instance
```
>>> sm.connect()
Traceback (most recent call last):
File "/home/amol/wrk/cpython/prova.py", line 17, in
sm.connect()
File "/home/amol/wrk/cpython/Lib/multiprocessing/managers.py", line 521, in
connect
conn = Client(self._address, authkey=self._authkey)
...
File "/home/amol/wrk/cpython/Lib/unittest/mock.py", line 1152, in
_execute_mock_call
raise effect
RuntimeError: BROKEN
```
To make things worse, we would actually randomly use XmlClient or new one
depending on which SyncManager method we call.
This makes also inconvenient to replace the connection layer with a fake one
during tests to simulate stub responses. Furthermore the client of the manager
is also not propagated properly to the proxies created through that manager
making even less consistent the behaviour.
--
components: Library (Lib)
messages: 366630
nosy: Alessandro Molina
priority: normal
severity: normal
status: open
title: multiprocessing.BaseManager does not retain Client type.
type: behavior
versions: Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40307>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26497] Documentation - HOWTO Use Python in the web paragraph on TurboGears still mentions it's based on Pylons
New submission from Alessandro Molina: https://docs.python.org/3.6/howto/webservers.html#turbogears still mentions "TurboGears 2 is based on the WSGI stack of another popular component-based web framework, Pylons." which is not true anymore since TurboGears 2.3.0. TurboGears switched to its own micro-framework core since version 2.3.0 as Pylons wasn't Python3 compatible. Also The TGBook is still mentioned even though it's 10 years old and not reliable anymore since TurboGears 1.0 -- assignee: docs@python components: Documentation messages: 261274 nosy: Alessandro Molina, docs@python priority: normal severity: normal status: open title: Documentation - HOWTO Use Python in the web paragraph on TurboGears still mentions it's based on Pylons versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26497> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
