update render_to_response to prevent renderers from mutating request.response

[mmerickel]

fixes #1536

I think this should be fairly non-controversial. When using render_to_response you'd probably expect that to not have any side effects on request.response which you may also end up using during the request. This patch just keeps them separate.

[mmerickel]

In 72bf6bb I added the ability to specify a custom response object as an argument. So if you need to modify some params prior to the renderer touching the object then you can just create the object and pass it in.

response = Response()
result = render_to_response('json', {}, request=request, response=response)
assert result is response # --> True

This PR very slightly backward incompatible since it was apparently documented to mutate request.response in the last sentence of the docstring, but I really think this is an improvement in usability. Previously you could really only call render_to_response once and you'd get subtle side-effects when calling it twice while sharing request.response. Not that many people would've called it twice in one request.

[digitalresistor]

It was documented that if you mutated request.response before passing request to render_to_reponse then those mutations would be visible to render_to_response. Nowhere did it state in that docstring (from the way I am reading it) that render_to_response would mutate request.response itself.

The one thing you could add to be backwards compatible to what was documented was to make a copy of the response object on request if no response is explicitly passed in.

[mmerickel]

What approach would you take? I'm still leaning toward my solution atm because I think it makes more sense. Compatibility has not yet dissuaded me.

[digitalresistor]

Honestly the original way was very unintuitive, I would go with your changes and call it good. I simply pointed out that the language used in the original docstring gave you some leeway to make a b/w compat fix.

[tseaver]

LGTM