Context Processors get top of stack in RequestContext instances

[teepark]

Currently, RequestContext.__init__ applies context processors after updating from the provided dictionary. This should be the other way around because context processors are so general in scope (automatically applied to every RequestContext in the whole site).

d = {'anint': 7}

# this would get masked by any context processor that provides 'anint'
def myview(request):
    return render_to_response("home.html", context_instance=RequestContext(request, d))

# so this form would be necessary
def myview(request):
    rc = RequestContext(request)
    rc.update(d)
    return render_to_response("home.html", context_instance=rc)

[teepark]

initial patch, no tests

[Malcolm Tredinnick]

This would have to be pre-1.0 if we do it, since it's backwards incompatible in a visible way. Could go either way, though. The idea is that context processors are orthogonal to the rest of the code and if you accidentally reuse a context processor variable, accidentally overwriting the context processor-intended result may not a good result. Of course, some people will want to be to able to replace them on a per-view basis, which may or may not be against the spirit of context processors.

For those reasons, moving to design decision needed. It needs thought.

[Luke Plant]

I agree with Malcolm -- the fact that context processors are so general could push the argument either way. However, if you want to override, you can just update the RequestContext object manually after creation, which for me makes the backwards incompatibility definitely not worth it. It's past 1.0 anyway now, so closing WONTFIX.