I think it's a mistake for Template.safe_substitute()
to raise a ValueError when the invalid group is
matched.  I just ran across such a situation in Real
Code that is using Template.  In my code, I'm using a
subclass to override idpattern and then calling
safe_substitute().  The source of the template is a
flattened mail message where what I'm substituting is
going into some of the header fields.

The body of the message contains a big blurb of XML,
including the string "...$1...".  Well, that $1
triggers the ValueError.

This patch changes the semantics of safe_substitute()
so that when the 'invalid' group matches, the original
delimiter is returned, which I think is the right thing
to do.  Included is an updated test (I will update the
docs too if you agree that this patch should be applied).

Logged In: YES 
user_id=1038590

I'd agree with those semantics - if an unrecognised
identifier doesn't trigger a Key Error, I see no reason for
a non-identifier to trigger a Value Error.

For people who want stricter checking - well, that's what
substitute() is for.

Logged In: YES 
user_id=80475

Simplify:
    return '%s' % self.delimiter
To just:
    return self.delimiter

Please add docs and Misc/NEWS entry, then apply.

Logged In: YES 
user_id=80475

The docs should spell-out that the safe in safe_substitute()
means that no exceptions will be raised except possible
memory errors.  In some sense, it is now anything but safe.
 It will silently skip past dangling delimiters, unclosed
braced identifiers such as ${oops, identifiers with
incorrect bracing such $<angled>, and idenfiers that aren't
valid python identifiers such as $1two3.

Logged In: YES 
user_id=12800

Committed, with doc updates.