Allow context processors to take the context as a second argument

[fberger]

It would be very useful if context processors could do what their name suggests and process the existing context and manipulate it instead of just adding and potentially overriding some existing entries in the context.

This would be useful for context processors that take entries contained in the context and compute an extra bit of information. If the entry is not there it wouldn't waste any time computing it for a view that doesn't need it and avoid extra db queries to get the data.

No guarantee would be given as to the order in which processors run, they could only rely on context data provided by views.

A workaround to achieve the same effect would be to set the context as field in the request.

I've attached a basic patch that allows context processors to optionally take a context argument.

[Luke Plant]

I'm not sure what to do with this.

I can see the use case, but I suspect it is out of scope for the original idea of context processors, and leads to a coupling between your views, which are meant to be specific to one task, and the data returned by context processors which is not. They are always other ways of achieving the same thing - for example your own Context subclass that does this, or computing the data in the view rather than in the context processor.

Also, using inspect.getargspec is not a panacea for backwards compatibility issues - there are many ways that it can fail, especially when decorators or classes are concerned. We would have to treat this as a backwards incompatible change.

[Jannis Leidel]

Yeah, I agree with Luke, while in theory maybe useful, this seems contrary to what the context processors are supposed to be doing. Closing as wontfix.