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
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/E2HN6C3DZZUR7P6JNLV3FEZKPX5OBQF3/
Code of Conduct: http://python.org/psf/codeofconduct/
