Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread Marc Tamlyn 
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"  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 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/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 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/CAMwjO1GEEWM_u4asOjpi6BXR9OmCqno%2BsTkq-g23wJyqZa%3D81w%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread Tom Christie 
> 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 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/a7af947a-8d78-4855-abaa-4625d896e0b6%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread François Schiettecatte 
Hi

Just wanted to pitch in as a user of django. I have used request.REQUEST before 
for a very specific need but I would +1 for it to go.

The question I would have though is for PUT and DELETE methods, would the 
parameters just wind up in request.POST? Maybe this suggests that renaming 
request.GET and request.POST to something else might not be a bad idea.

François

On Oct 18, 2013, at 9:13 AM, 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 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/9cc2400e-6a67-49cd-b5ea-6a03f4618482%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/2F987180-F479-47BF-9F68-8A3454027C01%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-18 Thread James Aylett 
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 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/9cc2400e-6a67-49cd-b5ea-6a03f4618482%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Shai Berger 
On Wednesday 16 October 2013 19:48:09 Aymeric Augustin wrote:
> 2013/10/16 Javier Guerra Giraldez 
> 
> > yes, they're different, but is there any value in emphasizing the
> > difference?
> 
> The main value lies in emphasizing the difference between HTTP GET and HTTP
> POST. That difference has security implications, especially with regards to
> CSRF.
> 
Also, GET is supposed to be a "read only" operation.

http://thedailywtf.com/Articles/The_Spider_of_Doom.aspx

-- 
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/201310161955.32716.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Aymeric Augustin 
2013/10/16 Javier Guerra Giraldez 

> yes, they're different, but is there any value in emphasizing the
> difference?
>

The main value lies in emphasizing the difference between HTTP GET and HTTP
POST. That difference has security implications, especially with regards to
CSRF.

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.

-- 
Aymeric.

-- 
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/CANE-7mXpmgE-kzMV9Bj-X%2BrUtoSJf493O11C6zo0itVOorn8Qw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Tom Christie 
+1 on removing it.
It's usage reinforces incorrect assumptions about the meaning and behaviour 
of `request.POST` and `request.GET`.

> It's hardly ever a good design pattern to handle GET and POST identically

I'd phrase is as "It's hardly ever a good design pattern to handle query 
parameters and request bodies identically", but otherwise exactly this, yes.

-- 
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/3e98864c-ba33-48bf-b693-8006e786dea5%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Javier Guerra Giraldez 
disclaimer: i'm in no way opposing the deprecation of request.REQUEST.
 still, i feel there are lots of bad reasons in PHP-land about
discouraging use of that feature (typically some imagined security
reasons). I'd like to see some good reasons besides aesthetics (yes,
it's ugly) and duplication of functionality.


On Wed, Oct 16, 2013 at 11:29 AM, Tim Chase
 wrote:
> On 2013-10-16 11:10, Javier Guerra Giraldez wrote:
>> On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger 
>> wrote:
>> > However, it does so by blurring the distinction between GET and
>> > POST parameters, which like other people here, I find
>> > disturbing.
>>
>> care to elaborate about that distinction?  both are user-provided
>> parameters included in the request.  the only difference i see is
>> about encoding.
>
> Because they're sent different ways.  POST variables in the request
> body, and GET parameters are in the URL.


same origin: the browser or any http client

same destination: the web app

same transport: the http request

encoded in different parts of the request (body vs url).

yes, they're different, but is there any value in emphasizing the difference?


-- 
Javier

-- 
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/CAFkDaoRgoDbLr4WEc43w%3DRc8yBMG%2B66LDkMFx_F95vJQyLELGw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Tim Chase 
On 2013-10-16 11:10, Javier Guerra Giraldez wrote:
> On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger 
> wrote:
> > However, it does so by blurring the distinction between GET and
> > POST parameters, which like other people here, I find
> > disturbing.
> 
> care to elaborate about that distinction?  both are user-provided
> parameters included in the request.  the only difference i see is
> about encoding.

Because they're sent different ways.  POST variables in the request
body, and GET parameters are in the URL.  But it's possible that a
parameter is provided via *both*, and (as Alex notes) the first
question in such a case is "where does it look first?"

I'm +1 on the eventual removal, possibly with a footnoted function
that lets you request the fallback easily if needed.  It's a
one-liner as Marc details:

  request.GET.get(key, request.POST.get(key))

or

  request.POST.get(key, request.GET.get(key))

depending on the priority you want.

-tkc





-- 
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/20131016112949.68b9d342%40bigbox.christie.dr.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Javier Guerra Giraldez 
On Wed, Oct 16, 2013 at 10:14 AM, Shai Berger  wrote:
> However, it does so by blurring the distinction between GET and POST
> parameters, which like other people here, I find disturbing.


care to elaborate about that distinction?  both are user-provided
parameters included in the request.  the only difference i see is
about encoding.

-- 
Javier

-- 
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/CAFkDaoRneuFj3y_N7hDtgDohygeuQM3e0w42-gN7gtqArhADUw%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Alex Gaynor 
Another +1 for removing it, it makes it way too easy to do something
unfortunate, and it's behavior is only really intuitive if you come from
PHP, otherwise my first question is, "Where does it look first!?!" every
time I see it used.

Alex


On Wed, Oct 16, 2013 at 8:14 AM, Shai Berger  wrote:

> On Wednesday 16 October 2013 15:52:56 John Paulett wrote:
> > 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  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.
> >
> There is a fine point this seems to miss: The current REQUEST isn't
> equivalent
> to "request.POST or request.GET", but is a merge of the two; it supports a
> login form posted to a url like https://example.com/login/?next=eg which
> your
> suggestion wouldn't deal with well.
>
> However, it does so by blurring the distinction between GET and POST
> parameters, which like other people here, I find disturbing.
>
> Shai.
>
> --
> 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/201310161814.07961.shai%40platonix.com
> .
> For more options, visit https://groups.google.com/groups/opt_out.
>



-- 
"I disapprove of what you say, but I will defend to the death your right to
say it." -- Evelyn Beatrice Hall (summarizing Voltaire)
"The people's good is the highest law." -- Cicero
GPG Key fingerprint: 125F 5C67 DFE9 4084

-- 
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/CAFRnB2VkKvt7%2BEm7jV71DAbXi8iMG4Bii3FGvuPXTGNKdzAwbg%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Shai Berger 
On Wednesday 16 October 2013 15:52:56 John Paulett wrote:
> 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  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.
> 
There is a fine point this seems to miss: The current REQUEST isn't equivalent 
to "request.POST or request.GET", but is a merge of the two; it supports a 
login form posted to a url like https://example.com/login/?next=eg which your 
suggestion wouldn't deal with well.

However, it does so by blurring the distinction between GET and POST 
parameters, which like other people here, I find disturbing.

Shai.

-- 
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/201310161814.07961.shai%40platonix.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread John Paulett 
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  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  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"  wrote:
>
>> The ticket now has a patch so I 
>> wanted to make sure the consensus is to more forward with this. Here's
>> the rationale from the ticket
>> :
>>
>> 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.

Re: #18659 -- Deprecating request.REQUEST

2013-10-16 Thread Marc Tamlyn 
+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"  wrote:

> The ticket now has a patch so I 
> wanted to make sure the consensus is to more forward with this. Here's
> the rationale from the ticket
> :
>
> 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.