Re: deprecate or undocument shorcuts.render_to_response()?
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, Aymeric Augustin wrote: > > 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 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/696757c2-6a55-4cfa-90a4-073c8b4a0f45%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: deprecate or undocument shorcuts.render_to_response()?
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 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/CANE-7mX9dYakqUN0vcDCeB--Z%2BYa8tCQaw4-D9H0dUj%2BAMW-Fg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: deprecate or undocument shorcuts.render_to_response()?
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 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
>
> On Tuesday, 22 December 2015 15:36:57 UTC, Tim Graham wrote:
>>
>> 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
>>
> --
> 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-developers+unsubscr...@googlegroups.com.
> To post to this group, send email to django-developers@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.
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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/CAMwjO1EKhcuejrZyss6qJJWE04cVpuZNPir5zoHxMo9CFd82Sg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: deprecate or undocument shorcuts.render_to_response()?
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
On Tuesday, 22 December 2015 15:36:57 UTC, Tim Graham wrote:
>
> 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
>
--
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-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@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.
deprecate or undocument shorcuts.render_to_response()?
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 -- 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-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@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/20ff14c5-cc4d-4cb8-97ab-95ccdb37ba90%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
