On Tue, Jun 23, 2015 at 12:32 PM, Tim <jtim.arn...@gmail.com> wrote: > The code below prints the following two lines, showing how the 'newkey' is > now inside the Client response, even though it was set in the worker. This > must be bad practice! In my real code, the response is no longer an instance > variable, which fixed the problem. It never had any business being bound to > the client anyway.
I agree. There may be reasons why the client would want to hold onto the response, e.g. caching, but there are none evident in the code you posted. What it *shouldn't* do if it's going to hold on to state like that is share it with external code without at least a contract defining allowed mutations. If the consumer can't reasonably be expected not to modify the shared state, then it should be copied, not shared. -- https://mail.python.org/mailman/listinfo/python-list
