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
On Tuesday, December 22, 2015 at 12:52:33 PM UTC-5, Aym
2015-12-22 18:34 GMT+01:00 Marc Tamlyn :
> 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.
--
You receive
I'd be in favour of just undocumenting it for now.
On 22 December 2015 at 16:27, Alasdair Nicol wrote:
> 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
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 corre
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 kee