#9081: [patch] More flexible render_to_response()
---------------------------------------------+------------------------------
Reporter: bhagany | Owner: ccahoon
Status: new | Milestone:
Component: HTTP handling | Version: 1.0
Resolution: | Keywords:
Stage: Design decision needed | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------+------------------------------
Comment (by bhagany):
@ccahoon - The approach in #10588 is completely acceptable to me. If you
feel better about that one, feel free to go with it instead, without any
complaint from me. However, it looks like you're getting some pushback
from your mentor :)
@mtredinnick - I was actually thinking of you when I was talking about
getting resistance, even though you hadn't spoken up on this ticket yet.
It just seems like the kind of thing you don't like. Is it your opinion
then that shortcuts should stay how they are pretty much indefinitely?
Also, out of curiosity, was it you disagreeing with Simon at DjangoCon off
mic here:
http://www.youtube.com/watch?v=M1Qr9rSBGBE&feature=PlayList&p=D415FAF806EC47A1&index=2#t=37m10s
?
I disagree with your position, obviously. Respectfully, my disagreements
with your position are:
1. You say it "works perfectly for what is intended", but I am forced to
wonder what you mean. From my point of view, render_to_response is
intended to avoid having to import a template loader, a context class, and
a response class all the time. This patch and #10588 simply increase the
efficacy of render_to_response with regard to that intent. I don't
understand how it can be claimed that this idea is beyond the scope of a
shortcut like this.
2. "can be done in a single line of code" - not if you count imports. A
niggly point, but still. Disliking the number of things I need to import
into a views.py is one of the major reasons I like the idea of shortcuts.
3. "Adding yet more complexity to the shortcut stops it being a simple
shortcut" - You seem to imply that render_to_response is already complex
with "yet", and then call it simple, which I find confusing. Further, I
dispute that either the original function, this patch, or #10588 can be
rightfully regarded as complex in any sense.
4. "since it's unnecessary" - This is not a disagreement per se, but of
course this patch is unnecessary. A shortcut by its very nature is
unneccessary. This is the reason I am calling for a discussion on the
direction of the shortcuts module as a whole, since anything that lands
there will run contrary to the usual "you can do that yourself" ethos that
(I think rightfully, most of the time) predominates responses to feature
requests.
I will bring up the larger issue on the development list.
--
Ticket URL: <http://code.djangoproject.com/ticket/9081#comment:13>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
