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 <[email protected]> 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" <[email protected]> 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 [email protected]. >> To post to this group, send email to [email protected]. >> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. 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.
