Ah yes that's true, totally forgot about request.body just then even though I was using it a few days ago. So yes renaming it would help in that regard as I do remember seeing a few S/O question where it's confused people in the past.
Mr Steven Mapes Software Development and Solutions E: st...@jigsawtech.co.uk (mailto:st...@jigsawtech.co.uk) P: 07974220046 (tel:07974220046) W: https://uk.linkedin.com/in/stevemapes/ This E-Mail and its contents are confidential, protected by law and legally privileged. Only access by the addressee is authorised. Any liability (in negligence, contract or otherwise) arising from any third party taking any action or refraining from taking any action on the basis of any of the information contained in this E-Mail is hereby excluded to the fullest extent of the law. In the event that you are not the addressee, please notify the sender immediately. Do not discuss, disclose the contents to any person or store or copy the information in any medium or use it for any purpose whatsoever. On May 6 2020, at 9:43 am, Adam Johnson <m...@adamj.eu> wrote: > > 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 🤷♀️ > > > > > Yes GET and POST are capitalized in HTTP, but then COOKIES is not (Set-Cookie > / Cookies headers), and FILES and META aren't direct references to anything > in HTTP. > > Also I'm not sure it's a particularly good argument. Capitalization inside > Python should be based upon the conventions of Python, not the conventions of > the system the code talks to. For example, we have SELECT ... FOR UPDATE in > SQL, but .select_for_update() in the ORM. > > > Hmmm. I have to say I think there are areas where we could get a better ROI > > on our time than this. > > > I think if we took the amount of time spent by users due to the confusion of > GET/POST, divided by the amount of time to make the code and docs changes, it > would come out with a relatively good ratio. > > My inspiration (or "the final straw") for making this proposal was a recent > forum question with confusion on the meaning of POST: > https://forum.djangoproject.com/t/ajax-post-to-view-not-displaying-content/2034 > . I'm pretty sure I saw another one in the past month but can't find it But > it's an issue I've seen repeatedly. I know I've even spent time figuring out > how I'd get the query params during a POST request. > > > please do not use request.form_data as that is also misleading as you can > > POST many more sources than form data such as with APIs. post_data would be > > much clearer. > > Steven - I think you're confused by the current name. request.POST *only* > contains POST'd form data. It does not contain other POST'd data, such as > JSON bodies. So perahps that's another point for the name change? > On Wed, 6 May 2020 at 09:29, Steven Mapes <st...@jigsawtech.co.uk > (mailto:st...@jigsawtech.co.uk)> wrote: > > 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. > > > > 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 > > (mailto: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 > > > > (https://groups.google.com/d/msgid/django-developers/b23d3b4a-9ff4-42ed-a08b-594f185b8d3b%40googlegroups.com?utm_medium=email&utm_source=footer). > > > > > -- > Adam > > -- > You received this message because you are subscribed to a topic in the Google > Groups "Django developers (Contributions to Django itself)" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/django-developers/Kx8BfU-z4_E/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > django-developers+unsubscr...@googlegroups.com > (mailto:django-developers+unsubscr...@googlegroups.com). > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAMyDDM19Ay4oAf26QaA8EyixrzDXHpXmFgtWijVf_%3D30W-gVBA%40mail.gmail.com > > (https://groups.google.com/d/msgid/django-developers/CAMyDDM19Ay4oAf26QaA8EyixrzDXHpXmFgtWijVf_%3D30W-gVBA%40mail.gmail.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/137322AE-3BF9-4B5F-B80D-7AC7EF298A6C%40getmailspring.com.
