Opened 16 years ago

Closed 16 years ago

Last modified 12 years ago

#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)

7453.diff (1.9 KB ) - added by Marc Fargas 16 years ago.
Fix.
7453.backwards.diff (2.3 KB ) - added by Marc Fargas 16 years ago.
Non silent backwards compatible version.

Download all attachments as: .zip

Change History (11)

comment:1 by Marc Fargas, 16 years ago

Owner: changed from nobody to Marc Fargas
Status: newassigned
Triage Stage: UnreviewedAccepted

comment:2 by Simon Greenhill, 16 years ago

...and the same confusion in #7234.

by Marc Fargas, 16 years ago

Attachment: 7453.diff added

Fix.

comment:3 by Marc Fargas, 16 years ago

Has patch: set

Attached patch fixes this, passes tests and updates docs accordingly.

comment:4 by Russell Keith-Magee, 16 years ago

milestone: 1.0 alpha
Triage Stage: AcceptedDesign 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.

in reply to:  4 comment:5 by Marc Fargas, 16 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 Marc Fargas, 16 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 ;)

by Marc Fargas, 16 years ago

Attachment: 7453.backwards.diff added

Non silent backwards compatible version.

comment:7 by Marc Garcia, 16 years ago

milestone: 1.0 alpha1.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 Malcolm Tredinnick, 16 years ago

Resolution: wontfix
Status: assignedclosed

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.

comment:9 by Jacob, 12 years ago

milestone: 1.0 beta

Milestone 1.0 beta deleted

Note: See TracTickets for help on using tickets.
Back to Top