I also thought it was a taken more form HTTP rather than PHP but if this is changed 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.
On Tuesday, 5 May 2020 22:26:34 UTC+1, Adam Johnson wrote: > > request.GET and request.POST are misleadingly named: > > - GET contains the URL parameters and is therefore available whatever > the request method. This often confuses beginners and “returners” alike. > - POST contains form data on POST requests, but not other kinds of > data from POST requests. It can confuse users who are posting JSON or > other > formats. > > Additionally both names can lead users to think e.g. "if request.GET:" > means "if this is a GET request", which is not true. > > I believe the CAPITALIZED naming style was inherited from PHP's global > variables $_GET, $_POST, $_FILES etc. ( > https://www.php.net/manual/en/reserved.variables.get.php ). It stands out > as unpythonic, since these are instance variables and not module-level > constants (as per PEP8 https://www.python.org/dev/peps/pep-0008/#constants > ). > > I therefore propose these renames: > > - request.GET -> request.query_params (to match Django Rest Framework > - see below) > - request.POST -> request.form_data > - request.FILES -> request.files > - request.COOKIES -> request.cookies > - request.META -> request.meta > > Since these are very core attributes and the change would cause a huge > amount of churn, I propose not deprecating the old aliases immediately, but > leaving them in with a documentation note that they "may be deprecated." > Perhaps they can be like url() or ifequal which came up on the mailing list > recently - put through the normal deprecation path after a few releases > with such a note. > > Django Rest Framework already aliases GET as request.query_params in its > request wrapper: > https://www.django-rest-framework.org/api-guide/requests/#query_params . > Therefore the name request.query_params should not be surprising. DRF also > provides request.data which combines request.POST and request.FILES, and > flexibly parses from different content types, but I'm not sure that's > feasible to implement in Django core. > > For reference, other Python web frameworks have more "Pythonic" naming: > > - Bottle: request.url_args, request.forms, request.files, > request.cookies, request.environ > - Flask: request.args, request.form, request.files, request.cookies, > request.environ > - Starlette: request.query_params, request.form(), > request.form()[field_name], request.cookies, scope > > One more note for those who might think such core attributes should be > left alone: Django 2.2 added request.headers as a way of accessing headers > by name. This is convenient as it avoids the need to transform the header > to the WSGI environ name. makes the code more readable, and in the process > reduces the potential for bugs. I believe this proposal is in the same vein. > > -- 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/3c6309ad-1af5-4c57-afa1-0c754143eb2f%40googlegroups.com.
