PEP 750: Tag Strings For Writing Domain-Specific Languages

PEPs
120

Thanks for the comments on our proposal. I’m going to respond specifically to comments by @erictraut , @godlygeek , @barry , and @ncoghlan , although I’m sure I’m missing some of this discussion, and see how we can improve this proposed PEP:

  1. Tag functions are called with a TemplateConcrete object, which is builtin, with a runtime-checkable protocol Template provided from typing. Template provides args (as now) and source (original string passed into the tag string) as attributes. One nice thing about the source attribute is that it can be used as a memoization key, and of course requires no additional computation. Hopefully it can also be used for i18n purposes.
  2. Tag functions can be decorated with @tag_evaluation('eager' | 'choice' | 'deferred'); use Literal for these choices; this decorator is available from typing. This decorator sets a dunder method, __tag_evaluation__. eager is the usual evaluation order, and the tag function guarantees it does this upon entry. 'choice' means that the tag function chooses which interpolations to evaluate, if any, in any order, before returning, but it does not retain the interpolation after it returns. deferred allows for the interpolations to be seen outside the scope of the tag function. Hopefully this decorator can support typing needs.
  3. No short prefix names, however if dotted names are added, there’s no such restriction for a dotted name. So lazy.f is a valid tag name.
  4. It might be desirable to have a t prefix, which simply returns a Template. I assume this will have eager evaluation semantics. (There are additional aspects discussed, but these seem to require additional enhancements to the interpolation syntax; that can be discussed separately.)
2 Likes