Template cache, {% extends %} and globals - design issue?

Say I have this template with an extends call:

foo.html:

{% extends 'base.html' %}

I load it:

jinja2_env.get_template('foo.html', globals=my_globals}

This causes two calls to Environment._load_template: First, for foo.html, the for base.html.

Environment._load_template caches both templates.

The crucial point is that for the second call, the “globals” parameter to Environment._load_template is missing my_globals.

If I now attempt to load the base template directly:

jinja2_env.get_template('base.html', globals=my_globals}

The cache will be used, and my globals will not be available.

Using 2.7.2

[sophiebits-humu]

If I understand correctly, the primary motivation for the cache is to avoid the cost of re-parsing the template HTML multiple times. My hope would be that Jinja could cache that parsing but return a new Template object, which should require only a single small allocation.

If Flask and Ansible don’t expose the ability to pass different globals in, then they wouldn’t be affected by a minor performance regression as long as the caching of templates without globals was not affected (I agree that that seems to be the more common usage pattern).

I would argue that even with a documented warning, this is a very large footgun (even if someone is not too likely to run into this, it can be an incredibly bad bug if it does crop up) and so would prefer a solution 2 or 3 – but a warning in the documentation would be still a significant improvement over the status quo.

[davidism]

It will be merged, along with all the other PRs we’ve gotten from the MLH program over the last 3 months. There have been so many I haven’t been able to get to them all yet.