http://docs.python.org/2/library/string.html#template-strings

This class could be more useful with the following example:

>>> from string import Template
>>> t = Template('$who likes $what')
>>> who = 'tim'
>>> what = 'kung pao'
>>> t.substitute(locals())
'tim likes kung pao'

This will help PHP folks to transition their .php files.

On Nov 28, 2013, at 05:07 PM, anatoly techtonik wrote:

This class could be more useful with the following example:

>>> from string import Template
>>> t = Template('$who likes $what')
>>> who = 'tim'
>>> what = 'kung pao'
>>> t.substitute(locals())
'tim likes kung pao'

This will help PHP folks to transition their .php files.

I'm not sure what you want to add to the class. Your example works out of the
box. See this for an approach my third party library takes:

http://pythonhosted.org/flufl.i18n/docs/using.html#substitutions-and-placeholders

There is nothing to add to the class itself. It is about expanding docs section with helpful examples. string.Template is undervalued, because it is hard to see how it can be more useful than standard string formatting functions. But for people coming from PHP world, this can be a good start. The docs just need an entrypoint that shows how to use locally defined variables in template string. PHP does this for strings automatically.

Using locals() in this fashion is a serious anti-pattern, I'm -∞ on the docs suggesting it.

@alex, have you seen http://pythonhosted.org/flufl.i18n/docs/using.html#substitutions-and-placeholders? I really like the brevity, and it is the function that does the magic, so it is fully transparent and you don't need to instantiate string.Template every time. I think its awesome.

Do you have some explanations why passing locals() to string.Template is anti-pattern? I understand that passing "all that you have" is not good, but from my past experience with PHP I can't remember any problems that there are more names than I used. It is templating after all - what do you want to protect from?

A few notes about flufl.i18n's style. We chose this (extracted from the GNU
Mailman project) because $strings are *way* less error prone for translators
than %s strings, especially when you consider that some languages change the
order of placeholders. The automatic extraction of substitutions from locals
and globals (under the hood, via the sys._getframe() hack) was critical to
making the source code readable, by avoiding not just duplication, but
triplication of names.

There is a potential security hole though - a malicious translator with access
to the source could analyze the local and global context in which the
translation+substitution is being made, and craft a gettext catalog that adds
some new substitutions that expose sensitive information. Given that most
translations get little scrutiny, this could be used as an attack vector for
users of some languages (though not English, since it's typically the source
language and thus not translated).

We've decided to accept the risks in exchange for the huge convenience. We've
never seen such an attack and if we did, we'd address it in the code by
manipulating the globals and locals to avoid the possibility of a leak. (We'd
also learn to never trust the translators that added the hack.)

Formatting with locals() and globals() should be used with careful. This is not the most idiomatic way of formatting. I think that the post in specialised blog would be better place for describing it than Python stdlib documentation.

Peoples coming from PHP world can use f-strings.

We should really restructure string.Template documentation to emphasize i18n. That's always been its prime use case, and f-strings don't change that (because f-strings are not really appropriate for translations). Before f-strings, string.Template had other common uses. But f-strings do fulfill most other cases where people were using string.Template, so let's make sure that distinction is clear to people.

Let's retitle this, then.

In that case bpo-20314 looks related.

I'll take this one, and see if I can address 20314 also.

New changeset 9f74deb by Barry Warsaw in branch 'master':
Improve the documentation for template strings (#856)
9f74deb