deprecate or undocument shorcuts.render_to_response()?

[Tim Graham]

In 2010/Django 1.3 when the render() shortcut was introduced Jacob proposed: "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?"

Russ replied: "There's no particular reason to keep both around, other than the code churn that deprecation would entail. 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."

https://groups.google.com/d/topic/django-developers/mOx9ddVTrPA/discussion

I wonder if there would be consensus to move forward with a deprecation of render_to_response() at this point? If not, we could remove render_to_response() from the docs (as we did with the @permalink decorator), or at least lessen its prominence so it's not confusing to new users about which function to use in new code. I started updating the docs by replacing all usage of render_to_response() with render().

https://github.com/django/django/pull/5853

[Alasdair Nicol]

I think that updating the docs to use render instead of render_to_response is an good change. Many of the CSRF problems that I see new users struggling with are solved simply by switching to render.

Since passing context_instance to render_to_response is deprecated in 1.8. If I understand correctly, that means that users are already going to have to update their code from

    return render_to_response('my_template.html',

                              my_context,

                              context_instance=RequestContext(request))

to

    return render(request, 'my_template.html', my_context)

You could argue it's not too much to ask users to change render_to_response(template, context) to render(request=None, template, context) at the same time.

Cheers,

Alasdair

[Marc Tamlyn]

I'd be in favour of just undocumenting it for now.

--
You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/f5203b95-0ed7-4fb0-8088-73829bede644%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Aymeric Augustin]

2015-12-22 18:34 GMT+01:00 Marc Tamlyn <marc....@gmail.com>:

I'd be in favour of just undocumenting it for now.

I would be fine with either keeping it in the docs with a "you probably want render() instead" note or removing it from the docs. Then in a few years we can deprecate it.

 

--

Aymeric.

[Tim Graham]

Okay, have pushed the doc changes and created a ticket [1] with the following timeline, "we'll start the deprecation in Django 2.0 which means it'll be removed in Django 3.0 (December 2019)."

[1] https://code.djangoproject.com/ticket/25978