Django

Code

Ticket #7453 (closed: wontfix)

Opened 6 months ago

Last modified 5 months ago

HttpResponse uses parameter "status" to set "status_code" which is mildly confusing.

Reported by: Simon Greenhill Assigned to: telenieko
Milestone: 1.0 beta Component: HTTP handling
Version: SVN Keywords: HttpResponse status_code
Cc: Triage Stage: Design decision needed
Has patch: 1 Needs documentation: 0
Needs tests: 0 Patch needs improvement: 0

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

7453.diff (1.9 kB) - added by telenieko on 06/14/08 08:07:26.
Fix.
7453.backwards.diff (2.3 kB) - added by telenieko on 06/19/08 17:24:17.
Non silent backwards compatible version.

Change History

06/14/08 07:57:41 changed by telenieko

  • status changed from new to assigned.
  • needs_better_patch changed.
  • needs_tests changed.
  • owner changed from nobody to telenieko.
  • needs_docs changed.
  • stage changed from Unreviewed to Accepted.

06/14/08 08:03:25 changed by Simon Greenhill

...and the same confusion in #7234.

06/14/08 08:07:26 changed by telenieko

  • attachment 7453.diff added.

Fix.

06/14/08 08:07:55 changed by telenieko

  • has_patch set to 1.

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

(follow-up: ↓ 5 ) 06/19/08 07:22:18 changed by russellm

  • stage changed from Accepted to Design decision needed.
  • milestone set to 1.0 alpha.

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 ) 06/19/08 11:29:26 changed by telenieko

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?

06/19/08 17:21:18 changed by telenieko

That's a backwards compatible version, which raises a PendingDeprecationWarning?, for some reason my python doesn't show them. But it gets raised ;)

06/19/08 17:24:17 changed by telenieko

  • attachment 7453.backwards.diff added.

Non silent backwards compatible version.

06/27/08 10:21:12 changed by garcia_marc

  • milestone changed from 1.0 alpha to 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.

06/30/08 02:01:54 changed by mtredinnick

  • status changed from assigned to closed.
  • resolution set to wontfix.

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.

Add/Change #7453 (HttpResponse uses parameter "status" to set "status_code" which is mildly confusing.)




Change Properties
Action