Hello, This is quite disruptive — says the guy who suggested to remove request.REQUEST a few years back — but I think we could go ahead and do it. The names proposed by Adam are good.
I read the concerns about <form method="GET"> (e.g. for search forms) where form data ends up in query_params and not form_data. I'd call this a feature :-) Here's why: - Users who don't know that GET queries mustn't have side effects and who don't want to bother will have an incentive to use a POST query to get the data in form_data; this is the safe option with regards to CSRF; - Users who understand the safety model of browsers and who can determine that their view isn't vulnerable to CSRF will understand that the form data is in query_params, because that's where it is really. Also, looking at various names between `form_data` and `form_data_decoded_from_x_www_form_urlencoded_post_body` (the technically correct name), I believe that `form_data` is the best compromise between clarity and terseness. Best regards, -- Aymeric. > On 5 May 2020, at 23:26, 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 > <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 > <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 > <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 > <mailto: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>. -- 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/233CC919-0AF2-466A-A9D6-00DF5DE72845%40polytechnique.org.
