#7453 closed (wontfix)
HttpResponse uses parameter "status" to set "status_code" which is mildly confusing.
| Reported by: | Simon Greenhill | Owned by: | Marc Fargas |
|---|---|---|---|
| Component: | HTTP handling | Version: | dev |
| Severity: | Keywords: | HttpResponse status_code | |
| Cc: | Triage Stage: | Design decision needed | |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | no | Patch needs improvement: | no |
| Easy pickings: | no | UI/UX: | no |
Description
HttpResponse uses the parameter status to set the attribute status_code. This is inconsistent and confusing. I suspect it's caused the problems found on #7046, and we should consolidate the usage to either status or status_code.
Attachments (2)
Change History (11)
comment:1 by , 17 years ago
| Owner: | changed from to |
|---|---|
| Status: | new → assigned |
| Triage Stage: | Unreviewed → Accepted |
comment:2 by , 17 years ago
comment:3 by , 17 years ago
| Has patch: | set |
|---|
Attached patch fixes this, passes tests and updates docs accordingly.
follow-up: 5 comment:4 by , 17 years ago
| milestone: | → 1.0 alpha |
|---|---|
| Triage Stage: | Accepted → Design decision needed |
Consistency is a good argument for this change, but this would be a backwards incompatible change (probably not a huge impact change, but a change nonetheless). If we're going to make the change, we need to do it pre v1.0. Marking for a v1.0 decision.
comment:5 by , 17 years ago
Replying to russellm:
Consistency is a good argument for this change, but this would be a backwards incompatible change (probably not a huge impact change, but a change nonetheless). If we're going to make the change, we need to do it pre v1.0. Marking for a v1.0 decision.
We can accept both status and status_code and raise a DeprecationWarning when status is set, it's just 3 more lines of code ;)
What do you think?
comment:6 by , 17 years ago
That's a backwards compatible version, which raises a PendingDeprecationWarning, for some reason my python doesn't show them. But it gets raised ;)
comment:7 by , 16 years ago
| milestone: | 1.0 alpha → 1.0 beta |
|---|
According to ticket organization defined in http://code.djangoproject.com/wiki/VersionOneRoadmap#how-you-can-help 1.0 alpha tickets should be just features in the Must have (http://code.djangoproject.com/wiki/VersionOneRoadmap#must-have-features) list.
Changing to 1.0 beta for marking as v1.0 decision.
comment:8 by , 16 years ago
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
Not worth it. You set status once when you initialise the response and that's it. There's not really any call for normal code to be poking at status_code, so it could be called flibble and people shouldn't care. It's certainly not worth adding so many lines of code just to avoid the backwards incompatible thing, but I think it's really not worth doing at all. We've had that parameter there for a while now and people are using it. Let's not break their code for no reason.
...and the same confusion in #7234.