PEP 750: Tag Strings For Writing Domain-Specific Languages

PEPs
112

I’ve started accumulating the ideas this thread is giving me for PEP 501 in an issue on the PEPs repo: PEP 501: improvements inspired by PEP 750's tagged strings · Issue #3904 · python/peps · GitHub

Some of the ideas there are also potentially applicable to PEP 750:

  • rather than passing the exploded list of template components as the template function arguments, instead pass a single iterable TemplateLiteral object (so for arg in args: in rendering functions instead becomes for segment in template:). This also makes it straightforward to handle Barry’s request to provide access to the entire input string for i18n catalog lookup.
  • TemplateText as a potential alternative name for the Decoded protocol
  • TemplateField as a potential alternative name for the Interpolation protocol
  • switch to eager evaluation by default, but allow {-> expr} to indicate lazy fields (with the same meaning as {lambda: expr})
  • note that template renderers can accept () as a field specifier (as in {expr:()}) to indicate that the template field is a callable that should be called at rendering time
  • note that passing strings as template field values provides a way to “template templates”, with the field values naming parameters to be used for later dynamic substitution via a method call (akin to str.format and str.format_map, but without having to reparse the formatting template on every invocation)

Edit: I realised that {expr:()} would be a much better convention than {expr}() for calling functions at rendering time (since it keeps the info as part of the TemplateField object rather than relegating it to the following TemplateText object)

7 Likes