I think this idea is promising but instead of doing it by adding new syntax and a totally different object, why not attach a __templates__ dunder member to every string but only OPTIONALLY populate it when a string is formatted? For every regular string it would just be None:
"".__template__
But if you create a string using an f string, you can provide a directive, as part of the format specification mini language, to store it:
s = f"{foo!t}"
...or a directive at the front of the string to store all the f string arguments:
s = ft"{foo}"
This would save the values marked for storage as a tuple of Template arguments in the __templates__ member for later. It may also be desirable for the Template object to store the name foo and the position in the string the foo object was formatted. So:
foo = "spam" s = f"{foo!t}"
Now instead of being None, s.__template__ would store an object recording the name foo, what was passed to foo, and the position:
s.__templates___ ( Template (name="foo", value="spam", position=(0,4)), )
You could do the same with positional f string arguments, but using an integer as the name. An html or log function would later use, or discard, the template information as it sees fit. On Fri, Jun 11, 2021, 6:23 AM Thomas Güttler <info@thomas-guettler.de> wrote:
Am Fr., 11. Juni 2021 um 11:10 Uhr schrieb Stephen J. Turnbull < turnbull.stephen.fw@u.tsukuba.ac.jp>:
Thomas Güttler writes:
Am Fr., 11. Juni 2021 um 03:17 Uhr schrieb Stephan Hoyer < shoyer@gmail.com>:
Unevaluated f-strings is a nice way to think about this functionality.
But they're not "unevaluated" in a lot of important ways. A better term might be "pre-assembled". :-)
Another use-case that comes to mind is logging. The Google Python style guide says not to use f-strings, for example, because it wants to be able to collect the unexpanded pattern strings and not waste time rendering unlogged messages: https://google.github.io/styleguide/pyguide.html#3101-logging
Thank you Stephan for this feedback. I added Logging to the draft: https://github.com/guettli/peps/blob/master/pep-9999.rst#logging
If this does solve the logging problem, it would be a killer app (but that still might not be enough, given that PEP 501 couldn't clear the bar and logging was a leading application for that PEP). Perhaps you should focus on that rather than the HTML escaping problem.
Hi Stephen,
I can't solve a problem which I don't know. Logging plays no big role in my development tasks any more. I use checks, metrics and sentry. In the past logging was important for me, but this changed.
But I am sure that the proposal can be used to improve logging.
Regards, Thomas
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/YEYP2P... Code of Conduct: http://python.org/psf/codeofconduct/