PEP 750: Tag Strings For Writing Domain-Specific Languages

PEPs
122

Would source be a DecodedConcrete instance, so the full raw text can also be accessed?

The other planned changes look good to me, including the idea of offering t as a builtin so PEP 750 becomes a true functional superset of PEP 501 (between the planned changes to 750, and the planned changes to 501, any remaining differences will almost entirely be in the way templating related code looks rather than how it works).

I’m still not convinced we actually need the extra step of generalisation to arbitrary string tag support, but with the revisions, it would be straightforward to devise a two step implementation plan: in step 1, add specific t-string support to the lexer and compiler (with eager evaluation), spend a release exploring what can be done with that more restricted version, and then decide whether or not to proceed with step 2 (adding the lexer and compiler support for arbitrary string tags, as well as the decorator to choose between eager, lazy, and selective field interpolation).

I spent some time yesterday thinking about aligning these templating proposals with string.Template in the context of PEP 501. At the time I was skeptical of the suitability, but I’m starting to see more merit in the possibility now.

However, it would come with some restrictions:

  • you’d be limited to the ${...} substitution form, since the compiler wouldn’t see $... as defining an interpolation field (whether the $ was required or optional would be up to the templating function)
  • to allow interpolating more than simple references to named variables, you’d need to adapt the specifier string to include a way of naming fields for i18n substition (for example, repurpose the specifier string as naming the field such that i18n"The result of adding ${x} to ${y} is ${x+y:expr_result}" or _(t"The result of adding ${x} to ${y} is ${x+y:expr_result}") would map to the English translation catalog entry The result of adding $x to $y is $expr_result. A regular specifier string could still be allowed after a second :, since colons are permitted in specifier strings)

With those caveats though, you’d be able to completely hide the retrieval of the relevant string.Template object for the active language (cached based on template.source, but initially looked up in the catalog based on a normalised form that strips out the details of expressions, format specifiers, and conversion specifiers in favour of just the field names) and then calling string.Template.safe_substitute on it with the interpolated values, without needing to do dynamic name resolution on the interpolated fields in the calling namespace the way translation functions currently have to do.