For me it's a good move (the best would be to have request.data as with
DRF).
I've done this kind of "upgrade" from Django request.{GET,POST} to DRF
request.{query_params,data} and it was quite trivial (search and replace).
At the same time it forced me to check the code for correctnes, and I found
a couple of (unrelated) bugs.
For me I'll add the alias as soon as possible (3.1?), use them in
documentation, and start the deprecation after an LTS release (4.0? 5.0?),
so there would be plenty of time to upgrade.On Tue, May 5, 2020 at 11:26 PM Adam Johnson <m...@adamj.eu> 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/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAMyDDM3%2BUucViDezhkWrFsk6ZsKViWjOgtA5aBm9pnzozdc%2Beg%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- | Raffaele Salmaso | https://salmaso.org | https://bitbucket.org/rsalmaso | https://github.com/rsalmaso -- 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/CABgH4Jvf7J0JOtdnXVGrR1Sg7-Q1q7TbUcGswMvmKKw-AwPd%3Dg%40mail.gmail.com.
