# PEP750: Template Strings (new updates) **URL:** \ **Category:** PEPs\ **Created:** [November 18, 2024, 5:44pm UTC](https://discuss.python.org/t/pep750-template-strings-new-updates/71594 "2024-11-18T17:44:56Z")\ **Posts on this page:** 1\ **Showing post:** 45
**Author:** ![davidism](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/davidism/32/3295_2.png) [@davidism](https://discuss.python.org/u/davidism)\ **Post date:** [December 1, 2024, 12:04am UTC](https://discuss.python.org/t/pep750-template-strings-new-updates/71594/45 "2024-12-01T00:04:07Z")
I guess I don’t know the true design history, but my assumption has always been that `| filter` was a convenience for template authors who are not developers, where `take_this | do_this | then _do_this` is easier to read in an otherwise text document than `then_do_this(do_this(take_this))`. Given that PEP 750 does not provide a way to write templates separate from Python code, we can assume anyone writing templates is also familiar with writing Python. Also, I’m not convinced I would add filter syntax if I was rewriting Jinja today. It’s caused confusion about operator precedence; many people are uncertain/surprised how the expression `a + b | c + d` evaluates. It still requires understanding Python syntax to pass arguments. And given that so much of the rest of Jinja looks like (and is) Python anyway, having a second way to apply functions doesn’t make the template as a whole particularly more readable. Similarly for the `a is test` syntax that converts to `test(a)`, and how those tests can also be used in filters. --- _[View the full topic](https://discuss.python.org/t/pep750-template-strings-new-updates/71594)._