I came across this piece of code in Lib/string.py:146:

    # We use this idiom instead of str() because the latter will
    # fail if val is a Unicode containing non-ASCII characters.
    return '%s' % (mapping[named],)

This seems vestigial. I think it'd be appropriate to "fix" the string.Template by replacing the printf-style formatting with newer str.format everywhere in the Template's source. The obvious advantage is that by tweaking some regexes we'll make possible formatting using the following syntax

    ${thing.attribute_or_key}

by dropping to the str.format

    return '{named}'.format(**mapping)  # <-- new version

It'd also make sense to use the str.format_map to implement the Template.safe_substitute.

Borrowing some ideas from issue1198569, we can then expose an additional attribute called Template.bracepattern to allow programmers use the str.format-based substitution extensively:

	$name
	${name.thing}
	${name.thing: >16}

This change won't break any existing code.

But I'm not exactly sure string.Template should be in Python 3 at all. It's one of the least used features and PEP 292 states it was added as an alternative to %-based substitution. I think it'd be deprecated and removed from the standard library.

So what's the resolution? Should we fix it or deprecate it or both?

> I came across this piece of code in Lib/string.py:146:

That may be artifact from the days of ASCII strings and may or may not have analog with the bytes data type.

> But I'm not exactly sure string.Template should be in 
> Python 3 at all.

It still has valid use cases (i.e. exposing safe templates to the end user).  And it has features that aren't present in new-style formatting.

Please learn an aversion to deprecating things (it almost never a good first reaction to seeing code in the standard library).  It almost always breaks someone's code and makes migrating to Python 3 more difficult.

I'm strongly -1 for deprecating string.Template. It provides simple, widely used syntax, and is used in a lot of third-party code. I don't think that it needs to be extended.

However I have an idea about implementing general string composing engine than could be reused with different frontends in str.format, str.__mod__, string.Template, re.sub, and third-part template engines. Perhaps I'll try to implement it in 3.6.

Ugh, I guess I was too quick to propose deprecation, sorry :(

But is it a strict "No" to the proposed use of str.format as well? This would be a (relatively) minor but useful change which, again, won't break anything.

I can write the patch.

Yes, I'm sure there is a lot of code that uses string.Template, partly because I've used it in at least three different projects for three different customers ;)

If you are willing to write a patch that might get superseded by Serhiy's code (if he decides to write it :), then I say go for it.  I'm not sure what coverage is like on the Template code (not that coverage by itself is enough!)...you might want to add some more tests to make *sure* we aren't breaking backward compatibility.

But, we should see what Barry thinks :)

And yeah, that line 146 thing is probably due to the unicode coercion issues with string formatting for which there are (I believe) more than one open issue in this tracker (the most recent one was in the warnings module, I think).

So yeah, we don't want to deprecate string.Template.  It has a very specific use case that's used a lot, i.e. making strings dead simple to translate.  %(foo)s was very problematic.  {foo} is a little better, but looks too weird for most translators.  $foo is very common, well understood, and hard to get wrong.

As for modernizing the code (the L146 bit was thanks to Python 2), I wouldn't be against it if it doesn't change the documented API or functionality and all the tests still pass (and there's good coverage - I don't remember anymore).  I don't think it's really that important though; typically these are not used in performance critical sections.

Re: ${thing.attribute} - no, that wouldn't keep them Simple and PEP 292 was deliberately targeting simplicity.

Bottom line: keep $-strings simple and focused on their original use case.  For more complicated use cases, use str.format().

New changeset 678a76610723 by Serhiy Storchaka in branch 'default':
Issue #24309: Removed Python 2 idioms.
https://hg.python.org/cpython/rev/678a76610723

Agree with Barry. And please note, that string.Template is not invented in Python, it is used in a lot of other languages, including shell, make, Tcl, Perl. One of the advantage is that these templates are cross-language.