On Aug 07, 2015, at 10:12 AM, Guido van Rossum wrote:
This is a big deal because of the worry about code injection. A "classic" format string given access to locals() (e.g. using s.format(**locals())) always stirs worries about code injection if the string is a variable. The proposed forms of string interpolation don't give access to locals *other than the locals where the string "literal" itself exists*. This latter access is no different from the access to locals in any expression. (The same for globals(), of course.)
I took a look at the Mailman trunk. It's definitely the case that the majority of the uses of flufl.i18n's string interpolation are with in-place literals. A few examples of where a variable is passed in instead: * An error notification where some other component calculates the error message and is passed to a generic reporting function. The error message may be composed from several literal bits and pieces. * Translate a template read from a data file. I'd put this in the camp of consenting adults. It's useful and rare, so if I saw non-literals in a code review, I'd question it, but probably not disallow it. I'd want to spend extra time reviewing the code to be assured it's not a vector for code injections.
The other issue with explicit locals() is that to the people who would most benefit from variable interpolation (typically relatively unsophisticated users), it is magical boilerplate. (Worse, it's boilerplate that their more experienced mentors will warn them against because of the code injection worry.)
Which is why I think it can't be implicit for all strings. E.g. in an i18n context, seeing _('$person did $something') is a very explicit marker.
I'm not sure what your point is here. (Genuinely not sure -- this is not a rhetorical flourish.) Are you saying that you prefer the explicit formatting operation because it acts as a signal to the reader that formatting is taking place?
Although I didn't say it, I'd answer this question "yes". Cheers, -Barry