This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vaultah
Recipients vaultah
Date 2015-05-28.04:25:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1432787130.33.0.724179416311.issue24309@psf.upfronthosting.co.za>
In-reply-to
Content
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?
History
Date User Action Args
2015-05-28 04:25:30vaultahsetrecipients: + vaultah
2015-05-28 04:25:30vaultahsetmessageid: <1432787130.33.0.724179416311.issue24309@psf.upfronthosting.co.za>
2015-05-28 04:25:30vaultahlinkissue24309 messages
2015-05-28 04:25:30vaultahcreate