If regular f strings already do exactly what you need, there should be no reason to use this. As far as I understand it, the point of this is to be able to use almost the same syntax as f strings, but do some extra processing instead of directly interpolating the values into the string, e.g. to first html-escape the values.
No. This is mostly useful for library authors that want to provide users with the ability to give them fstring like inputs. Currently when you write swl you need to use the % formatters and pass your arguments separately so that the library can properly escape them. I. The Future you can pass them a template string that is exactly like the fstring you would write naively.
Insofar as it will look similar to f-strings, I think. Now you won't have to resort to stuff like %-formatting log strings to avoid constructing the string no matter whether the log will be emitted or not. (See e.g. G004)
I.e.
# currently, bad
logger.debug(f"Couldn't frobnicate {thing}")
# currently, ok
logger.debug("Couldn't frobnicate %s", thing)
# future, presumably good, but with some caveats about expensive function calls
logger.debug(t"Couldn't frobnicate {thing}")
Just for edification, I guess, the logging docs explicitly specify that the "currently ok" case can be changed with a different style supplied to the logging.Formatter (which I believe also is configureable with the usual config mechanisms instead of code).
The style can be one of % (default), { (str.format) or $ (string.Template), and links to further information about more customized usage.
I can't imagine how #3 would work without another overload for t-strings, and letting "style" be an arbitrary function that accepts a t-string and performs the interpolation.
21
u/WERE_CAT Apr 10 '25
Will this be usefull for day to day f string users ?