Allow context processors to access and update existing context

Django Internals
1

While reviewing some application code today, I came across #13841 (Allow context processors access to current version of context) – Django

Given it’s been 11 years since the last comment I wanted to see get some consensus if this ticket was still a desirable change to make?

2

Hey @nanorepublica :waving_hand:

I’d suggest we can probably live without this addition.

Context processors are great, but a potential foot gun if not used sparingly. (It’s very easy to create performance issues, and hard to debug code.)

Updating vs overriding values set previously just seems like an hammer no one needs to be wielding. That it’s sat there so long suggests similar.

I’d be inclined to close it as wontfix.

1 Like
3

Can’t you already override existing values? Like if you have two context processors that both return a certain key, the last one wins?

That being said I find the statement “so that they can change values and not just override them” logically weird. Overriding is functionally the same as changing no? The only thing this change would do would be to enable a downstream context processor to dynamically react to behavior set by a previous context processor. And if you want that, why not just call the other context processor explicitly like:

def third_party_context_processor(request):
    return {‘foo’: something}

def my_context_processor(requesst):
    x = third_party_context_processor(request)
    if x[‘foo’] == 3:
        x[‘foo’] = 8
    return foo

And then remove third_party_context_processor from your settings, and only have my_context_processor in there. This seems easier to follow to me.

4

The situation I had yesterday which triggered me finding this ticket was as follows.

I have a context processor which checks feature flags so something like:

def flags(request):
    # some logic with getting data for flags that want to be available on every page
    return {
        "feature_flags": data
    }

I then had a view which was checking a specific extra flag so:

def view(request):
    # view logic

    return render(request, template, {
       # other context
       "feature_flags": {
           "extra_flag": True | False
       }
    })

In this specific case I moved the specific flag to be global, but my initial thought was if were possible for the view or the context processor to update the value of “feature_flags”.

Hence me finding the ticket. I don’t mind which way the consensus lands, hence the quick post.

5

Yes, exactly. The ticket is to modify in place, which is Meh (at least to me, currently — which is just to say, I’m not seeing the use-case.)

2 Likes
6

I’m currently Meh too and would vote to close as wontfix.

I think context processors are best used to add global variables that are lazy regarding data store interactions (post: Django: Avoid database queries in template context processors - Adam Johnson ). Perhaps the name “processors” isn’t ideal then, but it’s the one we have.

2 Likes