Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #93046
| References | <109aafce-613c-4d6c-9f78-4bbe424f5901@googlegroups.com> |
|---|---|
| From | Ian Kelly <ian.g.kelly@gmail.com> |
| Date | 2015-06-23 13:30 -0600 |
| Subject | Re: method returns object reference |
| Newsgroups | comp.lang.python |
| Message-ID | <mailman.732.1435087895.13271.python-list@python.org> (permalink) |
On Tue, Jun 23, 2015 at 12:32 PM, Tim <jtim.arnold@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.
Back to comp.lang.python | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
method returns object reference Tim <jtim.arnold@gmail.com> - 2015-06-23 11:32 -0700 Re: method returns object reference Ian Kelly <ian.g.kelly@gmail.com> - 2015-06-23 13:30 -0600 Re: method returns object reference Ned Batchelder <ned@nedbatchelder.com> - 2015-06-23 13:59 -0700
csiph-web