[Django] #32259: Rename request attributes
Django
-------------------------------------+-------------------------------------
Reporter: Adam | Owner: nobody
(Chainz) Johnson |
Type: | Status: assigned
Cleanup/optimization |
Component: HTTP | Version: master
handling |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
As discussed [https://groups.google.com/g/django-developers/c/Kx8BfU-
z4_E/m/lFXTF0IMCQAJ on the mailing list] (back in May):
> 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
The biggest concern on the mailing list was churn. Therefore we won't
deprecate the old names, but will document them as historical aliases.
--
Ticket URL: <https://code.djangoproject.com/ticket/32259>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Type: | Status: assigned
Cleanup/optimization |
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* owner: nobody => Adam (Chainz) Johnson
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:1>
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Type: | Status: assigned
Cleanup/optimization |
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by אורי):
What will happen to existing code who will use `request.GET` or
`request.META`?
I found out that we are also using `request.LANGUAGE_CODE`.
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:2>
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Type: | Status: assigned
Cleanup/optimization |
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* cc: אורי (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:3>
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Type: | Status: assigned
Cleanup/optimization |
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* stage: Unreviewed => Accepted
Comment:
I think the consensus was to have this.
Leaving the old API in place, documented just once in the `request` docs,
is sufficient to avoid a forced rewrite. So +1.
> (back in May)
Funnily enough this crossed my mind just yesterday too. :)
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:4>
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* type: Cleanup/optimization => New feature
Comment:
I'm going to call this a New Feature. It **will** need release notes.
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:5>
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by Adam (Chainz) Johnson):
> I found out that we are also using request.LANGUAGE_CODE.
Thanks. I'm not sure if this one is such high value to change, it's
capitalized to indicate that it overrides the setting.
> I'm going to call this a New Feature. It will need release notes.
Fair enough!
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:6>
Django
-------------------------------------+-------------------------------------
Johnson | (Chainz) Johnson
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* has_patch: 0 => 1
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:7>
Django
-------------------------------------+-------------------------------------
Reporter: Adam (Chainz) | Owner: Adam
Johnson | (Chainz) Johnson
Type: New feature | Status: assigned
Component: HTTP handling | Version: master
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:8>
Django
Reporter: Adam Johnson | Owner: Adam Johnson
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: wontfix
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* cc: Carlton Gibson (added)
* status: assigned => closed
* resolution: => wontfix
Comment:
Adam, thanks for creating a ticket. However, this change is really
disruptive and it will affect everyone. In the case of such changes, it's
crucial to have a strong consensus and clear significant benefits. I don't
see a strong consensus on the mailing list and benefits are not
convincing.
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:9>
Django
-------------------------------+----------------------------------------
Reporter: Adam Johnson | Owner: Adam Johnson
Type: New feature | Status: closed
Component: HTTP handling | Version: dev
Severity: Normal | Resolution: wontfix
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
Changes (by Mariusz Felisiak):
* stage: Accepted => Unreviewed
--
Ticket URL: <https://code.djangoproject.com/ticket/32259#comment:10>