Combined them would be very very bad and you would have the same problems as with $_REQUEST in PHP where you have to decide which one wins as you can make a POST to a URL with querystring where one of the parameters uses the same name as a element of the POST and but where the value is different. It's bad practice but it's valid
On Wednesday, 6 May 2020 08:00:56 UTC+1, Jure Erznožnik wrote: > > I agree. If anything, I've always had issues with GET & POST being > different entities in the first place, but never with their names. I would > really like to see an entity combining both of them. THAT one, maybe the > preferred way of doing so, would be lowercase, but RAW representations of > incoming data, I for one like them being upper case. Always makes me think > twice before playing with them. > > The content negotiation thingy is also something I would like to see more > time invested in: I have a project where I have to hack & slash DRF's > implementation in order to get what I want, but perhaps I'm tackling the > issue incorrectly. But that's beside the point. People will always try to > do stuff framework developers didn't think of. What's important is to give > them a platform where they can do so easily. > > LP, > Jure > On 06/05/2020 08:08, Carlton Gibson wrote: > > Hmmm. I have to say I think there are areas where we could get a better > ROI on our time than this. > > I always took the capitalisation of GET &co to come from HTTP > <https://tools.ietf.org/html/rfc2616#page-36> — I'd say that's where PHP > took it from too but 🤷♀️ > That they're a bit "unpythonic" (Meh™) is OK: they serve to remind that > request was ultimately mapped from an HTTP request, and most of that is > still available if you care to dig. > > <form method=GET ...> > > Then request.form_data -> Oh, where's my form data, if not in "form_data"? > Well it's in "query_params"... Hmmm > That's no better learning experience. Folks still have to learn how HTTP > maps to request properties. > > > ... better ROI... > > There's lots we might take from DRF. The one that's come up before, and > which for work was began, but only began, was content negotiation. > I'd rather see work/energy/effort spent there. > > Maybe we'd have different names if we began today. But this would be very > disruptive. > We've just had a discussion re url() suggesting that "deprecated but not > really" is an error on our part, and having two ways to do things > definitely isn't "pythonic". > So I'm inclined towards the range between -1 and -0 — but I haven't had my > coffee yet. 😝 > > Kind Regards, > > Carlton > >> -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-d...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/bc60e809-6390-44fc-a07a-ed6e0f9eef86%40googlegroups.com > > <https://groups.google.com/d/msgid/django-developers/bc60e809-6390-44fc-a07a-ed6e0f9eef86%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/b23d3b4a-9ff4-42ed-a08b-594f185b8d3b%40googlegroups.com.
