jimbaker
commented
2 years ago Implemented support for i-strings and the corresponding InterpolationTemplate in examples:
https://github.com/jimbaker/tagstr/blob/main/examples/interpolation_template.py
I believe this is a complete implementation as specified by that PEP, other than showing the optional logging integration, which would require writing a minimal expression parser that would work with any dynamically scoped variables (and thus showing the nice aspect of lambdafied expressions).
gvanrossum
pauleveritt
PEP 501 introduces i-strings, which are syntactically the same as f-strings (using
iinstead offas prefix) but return an object representing the entire i-string. The interpolations and their fields can be extracted from this.i"x" "y" "z"is equivalent toi"xyz". But this is not how f-strings work:f"{foo}" "{bar}"does not interpolatebar. (UPDATE: Maybe this part of PEP 498 wasn't settled when PEP 501 was written.)\escapes back. You could not tell whether the source saysi"h\x61m"ori"ham"-- the raw string is always"ham".format(t)to render the final string (though you can also explicitly callt.render()).html,sqletc. are supported as plain functions that take anInterpolationTemplateinstance, e.g.html(i"<body>{stuff}</body>"). This is probably less disturbing for users who are familiar with the status quo. (UPDATE: And avoids corner cases likefr,rf,Fr,Rfetc. being unavailable as tags.)!r,!s,!a) into explicit calls torepr(),str(),ascii(). (It doesn't need to recover the conversion letter from the template object.)About the logging module: Not lambdafying interpolation expressions may avoid some issues with turning plain variables into cells (though I'm not sure such issues exist), but means that there's a minimal cost when i-strings are used as logging arguments -- they are always evaluated (though not formatted or concatenated with the fixed parts). Then again, this is also the case for the current best practice -- passing those expressions as extra arguments to the logging function. However, PEP 501 notes that the logging module supports using various builtin attributes of log records (e.g.
%(name)ssubstitutes the log record name) and suggests that additional integration would be needed to request these (e.g.{'record.name'}would interpolate the log record name). PEP 501 doesn't specify exactly how this should be done, but suggests that the logging module would have to look at the raw text of the interpolated expression to distinguish this usage from interpolating a string variable whose contents happens to be'record.name'. At that point I'd much rather just have lambdafied interpolations. (UPDATE:) Sadly, using{name}to refer to the record name would be a user trap, since this would override any local variable whose name happened to be a log record attribute (there are over 20 of those).