Count me as a firm +1 for a Template.join method that operates only on Template objects.
I can think of 2 reasons, only one of which has been discussed here.
- Support building larger templates. I often build long, multiline strings by building a list of lines, then ending with a
"\n".join(lines)to produce the final string. (This is especially useful if some of the lines are optional or depend on business logic.) Since Template strings are intended for DSL uses, I can easily imagine wanting to build long, multiline templates (e.g. SQL queries) in this way.
I also learned early not to build strings via repeated addition - it seems odd to now explicitly encourage doing just that for templates (even if the same performance considerations no longer apply). - Combine a list of parameters like @dvarrazzo already suggested. While one could use a minilang in the format (like @MegaIng suggested) or a separate function to do this (like @layday suggested), neither of these options should preclude using something like
t" AND ".join(…)for a lower-level interface that performs escaping but otherwise lets the caller handle the detailed SQL query.
——————
That leaves a question of what types join should operate on.
Realistically, since join is just repeated addition, it should accept the same types as __add__. The direction of PEP 750: disallow str + Template strongly suggests addition will just be between Template objects, which means the same should apply to join.