Thomas Güttler writes:
I don't understand what you mean with "pragma %conditional_escape_everything". Could you please elaborate?
"Pragma" just means it's a way to switch on conditional_escape for all template variable accesses for the rest of the file. The main point is that Django already can conditional_escape all the template variable accesses if it wants to, but it doesn't. It can provide a way for the template author to conditional_escape all the template variable accesses if the author wants to, but apparently it doesn't do that either. I have to wonder why not.
That "safe" attribute is outside the scope of the PEP.
But it's not outside the scope of the PEP, because by using conditional_escape in the template_literal_to_safestring() example, you used the assumption that it's accessible. But that's only true if you pass "safe strings" straight through to the tokens in the TemplateLiteral. If you don't, conditional_escape in your example would escape a safe string. I don't see how you can guarantee that it won't if you allow full f-string syntax.
In Django this is solved via mark_safe(), conditional_escape() and fomat_html().
This isn't an explanation though. The question is if you are implementing a web framework that depends on returning something that is not a str in the tokens, how do you do that and still retain the power of f-string format expression syntax? Or are you proposing that a template literal be restricted to plain variables -- no expressions and maybe no format specs that involve constructing strs -- in the {}?
Please provide an example how to simplify `template_literal_to_safestring()` of the draft: https://github.com/guettli/peps/blob/master/pep-9999.rst#specification
That's not my problem. I do not want this PEP, but if you want to push it to completion, I want to be sure that it works well for the proposed applications. For the reasons above, so far I don't see how it can be a big win for the web templating application. I'm not clear on how it's a win for the logging application, either. Note that as proposed in your PEP, template literal syntax would be forbidden by Google for the same reasons that f-strings are: (1) the logging implementation can theoretically collect the patterns from .template as queryable strs, but that seems to be just wasted effort because they are just strs and not usable as TemplateLiterals, and (2) it always gets rendered (to TemplateLiteral), which is also wasted effort if the logging function has no logs to send it to. PEP 501 is intended to address both issues. Note that in this example (a slight extension of your example): while (theres_work_to_do_matey): if load > max_load: logging.warn(f'Load is too high: {load}') the f-string works because it is evaluated when 'warn' is called. The logging problem that PEP 501 addresses is this: load_warning = f'Load is too high: {load}' while (theres_work_to_do_matey): if load > max_load: logging.warn(load_warning) Here the f-string does *not* work because it's evaluated at the binding to 'load_warning', not at 'warn' time. Template literal syntax as in your PEP also fails, for the same reason. This works: load_warning = 'Load is too high: {load}' while (theres_work_to_do_matey): if load > max_load: logging.warn(load_warning.format(load=load)) but for some reason ;-) people hate that, and Google recommends load_warning = 'Load is too high: {load}' while (theres_work_to_do_matey): if load > max_load: logging.warn(load_warning, load=load) if the logging package supports it, which is still kinda ugly. But a PEP 501 i-string "just works" nicely: load_warning = i'Load is too high: {load}' while (theres_work_to_do_matey): if load > max_load: logging.warn(load_warning) (This assumes a future version of logging.warn that calls str() on the first argument if it is an InterpolationTemplate.)
He/she will see: `<h1>Hello {name}</h1>` is the way to create a HTML fragment and he/she will do so.
That's not interesting, though. The interesting question is what is an author of a consumer of TemplateLiteral going to do. I'll guarantee you she/he will see this fragment = ''.join([x for x, _ in template_literal]) somewhere. I hope she/he doesn't copy it! The problem here is that frameworks like Django, or even templating languages like Jinja, are quite heavy. People looking for more lightweight approaches are likely to grab on to template literals and implement a stripped-down "vocabulary" directly as Python functions and methods. If this is going to be implemented, I want this to work naturally for them, and not be more restricted (especially not if the restrictions are "don't do this or you'll be sorry" conventions like Google's Logging Style Guide!) than f-strings are. I'm NOT saying it won't "just work" in any of the applications suggested: I haven't done, and am not going to do, the necessary work to show it doesn't. I'm "just asking questions". But if I didn't ask them, eventually somebody will, and as PEP proponent you probably need to answer them. If you don't, I believe the risk that the PEP will be rejected increases. Steve