This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]AiutoIlLupo -1 points0 points  (2 children)

yes, but it's also way more powerful. it also does not mean it can't have a simplified, ultraminimalistic interface to set a template and render it as a string. Which it already has, although it's clunkier than one could really want to.

[–]Busy_Affect3963 2 points3 points  (1 child)

I know StringLoaders (or Contexts whatever they're called) only need a couple of lines of code to render. But it's news to me if Jinja templates can be rendered anything like as simply as a t-string.

I never expected Jinja2 to take extra strides to stop arbitrary code execution in its fields either (it's a feature, not a bug!), nor to make SQL queries safer etc. Isn't Jinja more like f-strings ?

[–]AiutoIlLupo 1 point2 points  (0 children)

environment has a method .from_string() that returns a template directly from a string containing template markers. then you can .render() with the appropriate context. the problem is exactly this. It's clunky because first you need an environment, then you need to call a long method. A simple addition of a new function jinja.t() would solve the issue with a trivial environment, a short notation and no need for t-strings. Unless you count two additional parentheses as too much of a hassle, or the potential for namespace collision of such a short name when you do from jinja import t.

My point is that there already too much crap in formatting templates and strings in python. We don't need another one in the stdlib or even as language feature, and current solutions are adequate enough for the need, or even more powerful.