On 12/01/15 05:16, Russell Keith-Magee wrote:
On Mon, Jan 12, 2015 at 12:59 PM, <[email protected] <mailto:[email protected]>> wrote: On 10/01/15 22:40, Collin Anderson wrote: Hi All, In talking to Aymeric and other developers, we're starting to think about the usefulness of global template context_processors. It seems to us that ideally you should only need the "request" context processor. You could even imagine removing context_processors all together and having render() and class based views simply put the request in the context. FWIW, I habitually replace the multiple default context_processors with a single custom processor which does the same thing. Then I add and remove context items in a single place as the project goes on. The same with third-party context_processors (they tend to be straightforward). Backwards compatability aside, is a list of functions better than a single function? From a performance point of view, a single function should have a *slight* advantage over multiple functions - there's only one name to resolve on startup, and individual function calls are moderately expensive operations in the Python VM. However, let's be clear - the advantage would be **SLIGHT** - verging on the point where it wouldn't be observable against background noise unless you have a *disturbingly* large number of context processors. It certainly wouldn't be my first port of call if I was looking to optimise a site. From an engineering point of view, you're gaining an almost imperceptible performance gain, in exchange for taking on the maintenance burden of code that is already being delivered and tested by others. Unless, of course, you're writing a single context function that calls the existing implementations - in which case you've just *decreased* site performance, because you're putting an additional function call on top of the existing overhead. tl;dr - this isn't a performance issue; it's a clarity of expression issue.
Performance isn't my concern at all, just "alternative-futuring". If you guys are talking about altering how global context works, for me I like the 'there is a single place in my code where I control what goes into the context' idea. But I take your point about maintenance burden.
-- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/m8vn7t%24ko5%241%40ger.gmane.org. For more options, visit https://groups.google.com/d/optout.
