A common use case for templates is partially replacing
placeholders in loops or method cascades. The
safe_substitute method of the Template class provides
rudimentary support for this as long as Templates do
not contain the "$$" escape. In cases where multiple
replacements are necessary, a new Template must be
created. This messes up the "$$" replacement.

An example:

.>>> from string import Template
.>>> a = Template('$a + $$ != $b')
.>>> b = Template(a.safe_substitute(a=1))
.>>> [ b.substitute(b=i) for i in range(3) ]
Traceback [...]
ValueError: Invalid placeholder in string: line 1, col 5

In the current implementation, there is no way of
getting around this problem.

I suggest adding a new class-method as constructor to
the Template class: "Template.from_template", that
takes a template, applies a safe_substitute with the
provided (kw)arguments and returns a *valid* Template
(not a string). However, this method *must not* replace
occurrences of "$$" in the original template.

The above example would then look like this:
.>>> from string import Template
.>>> a = Template('$va + $$ != $vb')
.>>> b = Template.from_template(a, va=1)
.>>> [ b.substitute(vb=i) for i in range(3) ]
[ '1 + $ != 0', '1 + $ != 1', '1 + $ != 2' ]

Stefan, could you provide a patch to move this forward, can this issue be closed, or what?

Here's a patch for Python 3.1, if anyone's still interested after 5 years. :-)

I actually am no longer interested (after 5 years), but if the patch solves the problem, it'd be good to apply it. Lacks a docs patch, though.

FWIW, the $name $$ $(name) convention is used many other contexts and I don't think there is usually support provided to not substitute $$.  Even if there were, there is a usability issue where the final substitution needs to be applied differently to get the effect of escaping.  Since the final step needs to be different anyway, it is no burden to just use the current string.Template and write $(dollar_sign) in-place of $$ and apply that substitution on the final step.

Also, the current API for extending string.Template is already complex.  IMO, it is not a good idea to add more options to something that was supposed to provide a simpler alternative to templating.