deprecating the "escape" half of django.utils.safestring (#24046)
Tim Graham
Aymeric raised this ticket [0] while working on multiple template engines:
"Since any data that isn't explicitly marked as safe must be treated as unsafe, I don't understand why we have EscapeData and its subclasses nor the mark_for_escaping function. It seems to me that we could keep only the "safe" half of django.utils.safestring and deprecate the "escape" half. As a matter of fact the "escape" isn't used meaningfully anywhere in Django."
I implemented a proof of concept to show what things would look like after the deprecation completes:
https://github.com/django/django/pull/6015
It removes usage of mark_for_escaping() and EscapeData in the template engine to give an idea of what the code might look like with them removed. It wasn't difficult to get the tests passing besides a couple modifications to tests in test_force_escape.py which don't seem like practical usage (chained usage of escape|force_escape).
Here's a test case that demonstrates a small behavior change that would happen:
@setup({'chaining111': '{% autoescape off %}{{ a|escape|add:"<script>" }}{% endautoescape %}'})
def test_chaining111(self):
output = self.engine.render_to_string('chaining111', {'a': 'a < b'})
self.assertEqual(output, 'a < b<script>')
The documentation for the escape filter says,
The escaping is only applied when the string is output, so it does not matter where in a chained sequence of filters you put escape: it will always be applied as though it were the last filter. If you want escaping to be applied immediately, use the force_escape filter.
My implementation changes this so that the escape filter no longer executes after all other filters (it runs conditional_escape() right away). This means that the above test fails and the output is: 'a < b<script>'.
The behavior of escape running last no matter its position
doesn't seem so intuitive, but it could be problematic to simply change
it. A way forward could be to deprecate the escape filter in favor of a new filter called conditional_escape which would simply call the function of the same name. With the new filter, template authors will get equivalent behavior to escape as long as they put this filter last.
Alternatively, we could raise a deprecation warning if the escape filter isn't last in the list of filters and then change the behavior to use conditional_escape() at the end of the deprecation period. This has the potential to be less safe for users, however, as a project might skip over the Django versions with the warnings and not realize the behavior has changed. On the other hand, I hope few users are running with autoscape off and writing code like the test.
What do you think?
Collin Anderson
--
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 django-develop...@googlegroups.com.
To post to this group, send email to django-d...@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9ac23f7b-40fa-4295-bad1-568e4ffbd72e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Collin Anderson
Aymeric Augustin
The behavior of escape running last no matter its position doesn't seem so intuitive
That’s putting it mildly, considering that Django explicitly makes the parallel between template filters and Unix pipes.
but it could be problematic to simply change it. A way forward could be to deprecate the escape filter in favor of a new filter called conditional_escape which would simply call the function of the same name. With the new filter, template authors will get equivalent behavior to escape as long as they put this filter last.
This is a bit annoying because we won’t end up with the best name: |conditional_escape instead of just |escape.
Alternatively, we could raise a deprecation warning if the escape filter isn't last in the list of filters and then change the behavior to use conditional_escape() at the end of the deprecation period.
This would be my inclination.
This has the potential to be less safe for users, however, as a project might skip over the Django versions with the warnings and not realize the behavior has changed. On the other hand, I hope few users are running with autoscape off and writing code like the test.