Cog works line-by-line, which sidesteps thorny quoting concerns, and makes it applicable to more syntaxes. It lets you use regular Python code instead of "html-ified" code in Jinja (for example).
Certainly if you are happy with Jinja, you should use it.
Yes, I mean, I can understand how it works technically. But in what situations is something like Cog so beneficial that it offsets using something more well-known like Jinja? Are these situations common?
Have you looked at TFA? there are some tweet messages of people using it
By focusing on the templating aspect i think you completely missed what cog does and what makes it valuable: cog is an in-place repeatable generator.
You don’t output to a separate location, the output is embedded right after the generator itself, and if the inputs have not changed re-running cog is a no-op.
Cog’s “templating” is a mean, not an end, and in the interest of providing maximal flexibility it’s no templating at all but straight python code procedurally generating an output.
You haven’t taken the time to understand what Cog does. It’s not equivalent to a tempting engine like Jinja or PHP… or f-strings.
Re:Cog resurgence
by linsomniac on Saturday January 15, 2022 @10:08AM
(#29946863)
I also immediately thought "why is this not jinja?", but then I realized that jinja cannot do what cog can: run arbitrary Python code. Yes, jinja includes a small subset of python things as filters, but jinja on purpose does not include arbitrary code.
Typical jinja use is you have a controller or some outside code like Ansible that creates objects for jinja to operate on.
Cog is less like PHP templating, or jinja, and more like a standalone jupyter static text generator.
• PHP, the poster example for template-based languages, seems to have spent all its recent years in development trying to get away from its HTML templating roots. I basically never see a PHP file in the wild which is using the old style with mostly HTML with sprinkles of PHP; it’s almost all pure PHP.
• Python has a perfectly good templating system in Jinja2, used by Flask and many others. Last I looked, even Django seemed to imply that they’d themselves would rather be using Jinja2 than Django’s own templating language. IIRC, Django even natively supports replacing its templating engine with Jinja2.
• For small-ish templates embedded inline in code, Python now has f-strings.
Therefore, I wonder: In what situation, exactly, would Cog, a PHP-style inline code templating system, be better than Jinja2 and/or f-strings? And would this benefit be worth the added cost of having yet another model of abstractions which few people would be familiar with?