Add an auto escape setting to the Django template engine

[Aidan Lister]

Passing Context(mydata, autoescape=True) is no longer effective when using the non-deprecated format:

    from django.template import engines
    engines['django'].from_string('hello {{person}}').render({'person': 'bob & co'})
    >>> 'hello bob & co'

vs

    from django.template import Template,Context
    Template('hello {{person}}').render(Context({'person': 'bob & co'}, autoescape=False))
    >>> 'hello bob & co'

This is a very useful feature when not generated HTML templates!

[Aymeric Augustin]

Unless I missed something, this was a private API. You can use the public API which hasn't changed in Django 1.8: ​https://docs.djangoproject.com/en/1.7/ref/templates/builtins/#std:templatetag-autoescape

[Aidan Lister]

So the background here is that I've got editable templates via a GUI for emails. The emails are plain text ... so forcing end-users to put {% autocomplete on %} at the top of every template seems pretty gross. Can we reevaluate this?

[Aymeric Augustin]

Can't you just keep using the same code? I don't think you should yet any deprecation warnings, do you?

Also it may be reasonable to add and autoescape option to the Django template library, similar to Jinja2.

[Aidan Lister]

Isn't Context() deprecated in 1.10?

[Aymeric Augustin]

Not when using django.template as a standalone template library.

[Aaron Elliot Ross]

Jef, Are you at the sprints? I'd like to help with this! (I'm aaronelliotross on slack / irc.)

[Jef Geskens]

​https://github.com/django/django/pull/5584

[Carl Meyer]

I don't believe the PR quite matches what Aymeric had suggested above ("add an autoescape option to the Django template library, similar to Jinja2"). The Jinja2 backend doesn't accept an autoescape argument to its render method, it has a global autoescape option for the engine, which is configured in the settings dict.

I think that the signature of a template backend's render method should remain consistent between backends, and consistent with the documented signature, and not grow ad-hoc backend-specific additions. It's intended to be a generic lowest-common-denominator API; in the common case it is not called directly on the backend, but by the generic render() method. Backend configuration options, on the other hand, are intended to provide backend-specific configuration.

Presuming we did this as a configuration option (to parallel the Jinja2 backend), your use case might require you to configure two instances of the DTL in your settings file, one with autoescape turned on and one with autoescape turned off.

Aymeric, do you have any additional thoughts here? Do we need a way to pass per-render backend-specific options? Should the documented signature of a backend's render method include **kwargs, to be interpreted as desired by the backend?

[Aymeric Augustin]

I confirm what Carl just said. This should be an option of the engine. The signature of render() should remain a lowest common denominator.

This is necessary for end-users to be able to override any template with their own version, written for their favorite engine.

[Jef Geskens]

Ok, I understand the vision. I will create a new patch :-) Thanks for the review!

[Aymeric Augustin]

I discussed this with aaronelliotross at the very end of the DutH sprints and quickly wrote a tentative implementation, which I'm attaching to this ticket. Aaron was planning to try it and write tests. You should attempt to coordinate in order not to duplicate efforts.

[Aaron Elliot Ross]

OK, pull request added (​https://github.com/django/django/pull/5610).

Jef, want to take a look and see what you think? Sorry I didn't get in touch earlier, I will add myself to the CC here!

[Jef Geskens]

I commented on the PR.

[Tim Graham <timograham@…>]

In 19a5f6d:

Fixed #25469 -- Added autoescape option to DjangoTemplates backend.

Thanks Aymeric for the initial patch and Carl for review.