Django - 为什么我需要使用render_to_response呢？

考虑以下内容：\n

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

\n一方面，render更加简洁和符合Python风格。另一方面，你使用request作为第一个参数，我觉得这是多余和令人困惑的。所以我开始想到更大的区别是什么...\n根据文档：\n

\nrender()等同于调用render_to_response()并使用context_instance参数强制使用RequestContext。\n

\n所以区别只在于使用RequestContext。那么RequestContext的重要性是什么呢？让我们再次看看文档：\n

\n一个特殊的Context类[...]与普通的django.template.Context有些不同。第一个区别是它以HttpRequest作为第一个参数。\n

\n好的。那几乎没有什么关系。\n

\n第二个区别是它根据您的TEMPLATE_CONTEXT_PROCESSORS设置自动填充上下文中的一些变量[...]除此之外，RequestContext始终使用django.core.context_processors.csrf[...]它被故意硬编码，无法通过TEMPLATE_CONTEXT_PROCESSORS设置关闭。\n

\n所以这是重要的部分-确保所有上下文处理器正常工作，特别是csrf。所以实际上，回到我第一个例子，这两个实际上是相同的：\n

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

\n现在，第二个例子显然更糟糕，整个过程似乎过于复杂。所以我的一个重要问题是为什么还要使用render_to_response？为什么不废弃它？\n我还想到了其他问题：\n

\n
1. 难道没有更好的方法来强制使用RequestContext作为默认值吗？

\n

2. 有没有办法避免将request作为参数传递？这实在是多余的。我找到了一个博客文章，展示了如何将render_to_response转换为易于使用的装饰器。我们不能用类似的方法来处理render吗？

\n

3. 对于这个问题（如果它确实是个问题），有没有任何考虑？我在未来废弃计划中没有看到任何相关内容。我觉得这很令人困惑，因为render是在django 1.3中提出来的，专门解决了render_to_response的问题，而且大家都同意 不应该使用 render_to_response

\n

\n我知道这似乎有点离题，但我希望能得到解释为什么render_to_response仍然存在和/或使用render_to_response优于render的使用案例的答案（如果有的话）。