+1 request.query_params
If request.method == "POST":
thing = request.GET.get("thing")
That’s just silly.
+1 request.data
We shouldn’t be POSTists, there is also PUT and PATCH.
And apparently GET requests can also have a body:
https://stackoverflow.com/questions/978061/http-get-with-request-body
+1 No combining
Because.
+1 For 27 years deprecation cycle.
But in reality vast majority of codebases will only need a simple search
and replace, no? (Famous last words I guess...)
On Wed, 6 May 2020 at 16:08, אורי <u...@speedy.net> wrote:
> Hi,
>
> I also prefer lowercase names since uppercase is usually reserved for
> constants in Python. The names of the requests ("GET" / "POST") can be used
> in strings to check the request method (uppercase). But there is no sense
> in using uppercase names for variables.
> אורי
> u...@speedy.net
>
>
> On Wed, May 6, 2020 at 12:26 AM 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>
>> .
>>
> --
> 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/CABD5YeEFsbneB%3DfPKpE90cNukOUAKZejfp4Yo1N712mkmNVQHQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CABD5YeEFsbneB%3DfPKpE90cNukOUAKZejfp4Yo1N712mkmNVQHQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>
--
LP,
Fran
--
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/CAM2o%3DwPf%2B_p2vh%3Ds9C_O03jebgQ%2Bd%2Be9oODnLoJ_HdM58HSJqg%40mail.gmail.com.
