> 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.

Reply via email to