Django - Why should I ever use the render_to_response at all?

Question

consider this:

return render(request, 'index.html', {..context..})
return render_to_response('index.html', {..context..})

On the one hand, render is cleaner and more pythonic. On the other, you use the request as your first argument which I find redundant and confusing. So I started wondering about the bigger differences...

According to the docs:

render() is the same as a call to render_to_response() with a context_instance argument that forces the use of a RequestContext.

So the difference is only in using RequestContext. So what's important about RequestContext? Let's look at the docs again:

a special Context class [...] acts slightly differently than the normal django.template.Context. The first difference is that it takes an HttpRequest as its first argument.

Ok. That hardly matters at all

The second difference is that it automatically populates the context with a few variables, according to your TEMPLATE_CONTEXT_PROCESSORS setting [...] In addition to these, RequestContext always uses django.core.context_processors.csrf [...] it is deliberately hardcoded in and cannot be turned off by the TEMPLATE_CONTEXT_PROCESSORS setting.

So this is the important part - making sure all context processors work properly, with an emphasis on csrf. So really, to go back to my first example, these are actually the same:

return render(request, 'index.html', {...})
return render_to_response('index.html', {...}, context_instance=RequestContext(request))

Now, The second example is obviously far worse, the whole thing seems woefully overcomplicated. So my big question is Why use render_to_response at all? Why not deprecate it?

Other questions that come to mind:

1. Isn't there a better way to enforce RequestContext as the default?
2. Is there a way to avoid passing request as an argument? It's terribly redundant. I found a blog post showing how to make render_to_response into an easy to use decorator. Can't we do something similar with render?
3. Is there any thought about this issue (if it is an issue at all)? I see nothing of it in the future deprecation timeline. I find it especially confusing, considering render came about with django 1.3 specifically to address the problems with render_to_response, and that everyone agrees you shouldn't use render_to_response

I know it seems a little off-topic, but I'm hoping to get answers that will explain why render_to_response is staying around andor examples of use-cases where using render_to_response will be preferred over render (if there are any)

Answer 1

Most of the apps use render_to_response since it was the default recommended option since the very beginning until Django 1.3. The reason for the coexistence of both is historical, deprecating render_to_response will force a lot of code to be rewritten, which is not polite in minor releases. However in this django-developer thread they say it would be possible to include in the deprecation timeline for 2.0.

Here's the quote by Russell Keith-Magee, one of Django's core developers. Keith-Magee answers a question posted by Jacob Kaplan-Moss, another Django contributer who raises the question of deprecating render_to_response:

I think we should deprecate render_to_response() in favor of render(). render_to_response() is just render(request=None, ...), right? Any reason to keep both around? There's no particular reason to keep both around, other than the code churn that deprecation would entail.

And Keith-Magee answers:

This is something that I have no problem deprecating on the 2.0 schedule, but migrating every use of render_to_response() over the next 18 months/2 releases seems like an extreme measure to enforce on the entire user base when maintaining render_to_response() doesn't take any real effort.

Nobody's been discussing that deprecation, but I guess the answer for your question is: There's no technical reason, it's just their intent not to force an update on all the codebase in a minor (at least no major) release.