Seems to me an intermediary step is to add request.DATA (then maybe request.QUERY eventually) as a long term movement towards being better http. It isn't something we should do overnight.
I noticed this patch is now in 1.7 and 1.9 will remove request.REQUEST. Marc On 18 Oct 2013 14:55, "Tom Christie" <[email protected]> wrote: > > but perhaps we should provide better names for `request.GET` and > `request.POST` at the same time > > Sure, I'd absolutely agree in principle, and for what it's worth REST > framework provides `.QUERY_PARAMS` and `.DATA` attributes on the request > which are recommended instead of using `.GET` and `.POST`. Of course the > .DATA attribute in that case provides general purpose request parsing, and > isn't limited to form content types. > > The current names are fundamentally incorrect, and I think they help sow > the seeds for newcomers to misunderstand the basics of HTTP as a result. > > Having said that, in practice I don't know if they're something we'd ever > move away from. > > I don't really feel in any position to judge how we weigh up the current > naming awkwardness versus the pain of introducing such a major API > difference. > > > On Friday, 18 October 2013 14:13:48 UTC+1, James Aylett wrote: >> >> On Wednesday, October 16, 2013 5:48:09 PM UTC+1, Aymeric Augustin wrote: >> >> >>> While pour point is technically valid as far as request.GET and >>> request.POST are concerned, in practice they're so commonly used as a >>> metonymy for HTTP GET and HTTP POST that it's worth having a strong stance >>> on keeping them separate. >>> >> >> I'm not entirely serious, but perhaps we should provide better names for >> `request.GET` and `request.POST` at the same time (with compat). One >> contains some parameters from the request URL (but can be provided on any >> HTTP verb, not just GET), the other contains data from the request entity, >> providing it comes in one of two convenient formats that have common usage >> (and can be provided on various HTTP verbs, not constrained to POST). The >> current names are misleading if you try to learn HTTP by learning Django >> (and I'm guessing a lot of people do). >> >> Certainly the ?next / next= case pointed out above by Marc (a pattern I >> use a fair amount) would read more precisely (in the absence of >> `request.REQUEST`, which is a clunky, blurry, quite possibly misguiding but >> technically no worse named convenience). >> >> I'm +1 on deprecating `request.REQUEST`, and maybe +0 on the rest of what >> I've just said ;-) >> >> J >> > -- > 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/a7af947a-8d78-4855-abaa-4625d896e0b6%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/CAMwjO1GEEWM_u4asOjpi6BXR9OmCqno%2BsTkq-g23wJyqZa%3D81w%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
