I'll chime in with a counterpoint.
request.REQUEST can be helpful in limited cases when the server application
simply does not care whether it is receiving data via a GET query string or
x-www-form-urlencoded POST and a different clients can choose which form
method is appropriate for its use case (e.g. possibly due to query
string length
restrictions <http://stackoverflow.com/a/812962/82872> in some browsers).
I won't claim this approach is ideal, but I have found it useful on
occasion. Also, I acknowledge that a simple replacement could be "REQUEST
= request.POST or request.GET". If request.REQUEST ends up being removed,
I would not be upset, but I did want to state that I use it.
John
On Wed, Oct 16, 2013 at 8:04 AM, Marc Tamlyn <marc.tam...@gmail.com> wrote:
> +1 to deprecating this. In the rare cases where it is useful (mainly
> 'next' for redirects) it is very easy to work around it not being there -
> request.GET.get('next', request.POST.get('next')) - so I see no reason for
> it to always exist.
>
> In most cases I feel its use is not a good idea™…
>
> Marc
> On 16 Oct 2013 12:14, "Tim Graham" <timogra...@gmail.com> wrote:
>
>> The ticket now has a patch <https://github.com/django/django/pull/1756>so I
>> wanted to make sure the consensus is to more forward with this. Here's
>> the rationale from the ticket<https://code.djangoproject.com/ticket/18659>
>> :
>>
>> request.REQUEST provides indifferent access to request.GET or
>> request.POST (PHP style).
>>
>> This attribute is a legacy from the pre-1.0 days, when you could access
>> the GET or POST data using dict syntax on the request object.
>> request.REQUEST was introduced in 1.0 to make this operation more
>> explicit, with an easy upgrade path.
>>
>> It's hardly ever a good design pattern to handle GET and POST identically,
>> and it's our responsibility not to provide tools who are more likely to
>> result in bad code than anything else. So I think it's time to deprecate
>> this attribute.
>>
>> We could deprecate django.utils.datastructures.MergeDict at the same
>> time — it's a 100-lines long class whose sole purpose is to support
>> request.REQUEST.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Django developers" 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 http://groups.google.com/group/django-developers.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/d5946498-942d-4f47-8446-4eebfdf64f7c%40googlegroups.com
>> .
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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 http://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAMwjO1GQUrWxjZ8Z_vfNHPbxXMxWBFyvbQgDkUn9dqatKvcR4A%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CANRBGvZMkbasbBPbnHfHT%3D%2Bv8F-2%3DBwXFYrrbt9PUK9UOAxLGw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
