Opened 16 years ago

Closed 12 years ago

#10504 closed Cleanup/optimization (fixed)

Consistency between HttpResponse* params and render_to_response

Reported by: Brent Hagany Owned by: nobody
Component: HTTP handling Version: 1.0
Severity: Normal Keywords:
Cc: brent.hagany@…, Riccardo Attilio Galli Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: yes UI/UX: no

Description

I was just browsing through some of the Django code and came across the new-ish (to me) addition of the content_type alias for the mimetype parameter to HttpResponse and company. Wondering about the rationale behind this decision, I came across ticket #3526, which may be helpful to review in evaluating this ticket.

In light of this, (and just for consistency) I thought it would probably be a good idea to allow render_to_response to pass content_type along to HttpResponse. I'll attach a simple patch that does this.

Also, this patch will conflict with another patch (#9081) I've submitted that has been accepted but not yet committed. It'll be very easy to resolve, but I'm unsure if I should take any special measures about this.

Attachments (2)

content_type_in_render_to_response.diff (1.2 KB ) - added by Brent Hagany 16 years ago.
tkt-10504.diff (3.6 KB ) - added by kenth 13 years ago.

Download all attachments as: .zip

Change History (19)

by Brent Hagany, 16 years ago

comment:1 by Brent Hagany, 16 years ago

Cc: brent.hagany@… added
Has patch: set

comment:2 by Brent Hagany, 16 years ago

Component: UncategorizedHTTP handling

comment:3 by Jacob, 16 years ago

Triage Stage: UnreviewedAccepted

comment:4 by Roland van Laar, 15 years ago

Needs tests: set

Needs tests.

comment:5 by Brent Hagany, 15 years ago

My initial reaction - really?

1) Nobody has found it necessary to write a single test for a shortcut before (unless I just don't understand where they would be)
2) This is less than a one line change
3) This ticket has been touched by a core committer and accepted, despite the absence of tests.

So, I mean, I can do this. But because of these things, I had been working under the assumption that it was not necessary. Please advise.

comment:6 by ccahoon, 15 years ago

Needs tests: unset

@bhagany As I understand it, "Accepted" means that he thinks the general idea of the ticket is valid, not that the patch is accepted. If the patch was accepted, jacob would have committed the changes. I think it's a fine patch, though. I found this ticket looking to see if someone had already done the work I was about to on my GSoC branch, and there yours is. I am going to apply your changes to my SoC branch, so it will be bound to get reviewed within a month or so.

comment:7 by ccahoon, 15 years ago

@bhagany Actually, I will probably spend some time hopping between the two patches you've submitted and get advice from my mentor. They both look good, but the other is indeed very flexible, and I don't see any problems with it yet.

comment:8 by Brent Hagany, 15 years ago

@ccahoon Sounds great! I've been following the work in your branch, and I'm happy to have saved you a teensy bit of work.

Also, re: accepted status - noted, and thanks for explaining.

comment:9 by Chris Beaven, 15 years ago

ccahoon: have you fixed this in your branch? (if so, update the triage stage)

comment:10 by Chris Beaven, 14 years ago

Severity: Normal
Type: Cleanup/optimization

comment:11 by Julien Phalip, 14 years ago

Needs tests: set

comment:12 by Dougal Matthews, 13 years ago

Easy pickings: set
UI/UX: unset

by kenth, 13 years ago

Attachment: tkt-10504.diff added

comment:13 by kenth, 13 years ago

Needs tests: unset

Added tests for new shortcut.

comment:14 by anonymous, 12 years ago

Resolution: invalid
Status: newclosed

In [da200c5e35cd] (in response to ticket #16519 ) mimetype has been deprecated, so the patch isn't anymore needed.

comment:15 by Riccardo Attilio Galli, 12 years ago

Cc: Riccardo Attilio Galli added

I sat the resolution to invalid erroneously as anonymous, ccing now to follow evenctual future messages

Last edited 12 years ago by Riccardo Attilio Galli (previous) (diff)

comment:16 by Claude Paroz, 12 years ago

Patch needs improvement: set
Resolution: invalid
Status: closedreopened

In [da200c5e35cd], we didn't address the render_to_response inconsistency, so I think that the attached patch still makes sense. We should however introduce a deprecation path for the mimetype argument also.

comment:17 by Tim Graham, 12 years ago

Resolution: fixed
Status: reopenedclosed

Deprecating of mimetype in render_to_response completed in #19692 and 89cb771be7b53c40642872cdbedb15943bdf8e34.

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