PEP 498: Literal String Interpolation

PEP 498 adds a new string prefix which allows simpler string formatting by embedding expressions inside string literals. The expressions are evaluated and inserted into the resulting string value:
There's been a lot of discussion about this on python-ideas, much of which has been incorporated in to the PEP. Now I feel it's ready for python-dev input. Note there's a companion PEP 501 which extends this idea by delaying converting the expression into a string. This allows for more control over how the expressions are converted in to strings, and allows for non-string conversions as well. I have a complete implementation of PEP 498. I'll shortly create an issue and attach the patch to it. -- Eric.

On 30 August 2015 at 23:41, Eric V. Smith <eric@trueblade.com> wrote:
For the benefit of folks that weren't following the (many) iterations on python-ideas: PEP 501's general purpose string interpolation started out as a competitor to 498, but as the discussion continued and my ideas started to converge more and more with Eric's, I eventually realised it made more sense as an optional extension to PEP 498 that exposed the inner workings of the scope aware interpolation machinery to Python code. As part of that, I'm +1 on PEP 498's literal string interpolation syntax. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 2015-08-31 9:10 AM, Nick Coghlan wrote:
If PEP 501 is an extension to PEP 498, then the proposal is to add i'' prefix *in addition* to f'', right? If so, I think it might be confusing to a lot of people on what prefix should be used and when. I think it's too easy for an average user to write ``os.system(f'...')`` and think that their code is fine, instead of ``os.system(i'...')``. What's worse, is that there is no way for ``os.system()`` to reject the former use. Second, given that we use "f" for "formatted", using "i" for "interpolated template" is a bit confusing. Can we use "t" ("template strings")? Yury

On 8/31/2015 4:08 PM, Yury Selivanov wrote:
That would be my intention, yes. Your only other choice to get plain strings from a template would be to always say format(i'{expression}'), which I don't think is an improvement.
That's all correct. I have to say that I like PEP 501 mainly for its non-string use cases. That is, interpolators that don't produce strings. Note that this isn't possible with PEP 502's proposal.
I don't really care so much about the prefixes. I'd be okay with PEP 498 being either 'f', 'i', or 't'. I could warm up to 't' easier than 'i'. Eric.

On 8/31/2015 5:07 PM, Eric V. Smith wrote:
Let me rephrase that: with PEP 502, it must be possible to produce a string from every e-string (as they're called there), and since types.ExpressionString derives from str, it's even easier to misuse them as strings and not provide the correct interpolator. This is as opposed to PEP 501, where the equivalent type is not derived from str, and you must call format() or a custom interpolator to get a str. But back to PEP 498: I can't imagine accepting either PEP 501 or 502 without also accepting PEP 498. And once you've accepted 498, are i- or e-strings sufficiently powerful and useful enough, and are they likely to be used in the correct way? I think that's the question. Eric.

On 1 Sep 2015 07:35, "Eric V. Smith" <eric@trueblade.com> wrote:
Exactly, 498 should now be considered independently, with 501 & 502 as potential answers to questions like: * how can we mitigate the increased risk of code injection vulnerabilities that comes with native interpolation support? * how can we handle cases where delaying interpolation would be helpful, like event logging or i18n? * how can we support adaptation of the interpolation syntax to cases like SQL Alchemy's "text" API, which consumes an SQL expression in text form and converts it to SQL Alchemy objects? Writing 501 has satisfied me that those questions *can* be addressed, *if* we decide they should be, and that it can be done in such a way that it can be presented to folks learning Python in the future as an implementation detail of the native string formatting support (that is, folks would be taught formatted strings early, and only later be taught that you can use an interpolation template to split up the template interpolation and template rendering steps. That all adds up to thinking it's fine to defer answering those questions to later, rather than expecting 498 to address them immediately. We have plenty of time until 3.6 rolls around :) Cheers, Nick.

On 30 August 2015 at 23:41, Eric V. Smith <eric@trueblade.com> wrote:
For the benefit of folks that weren't following the (many) iterations on python-ideas: PEP 501's general purpose string interpolation started out as a competitor to 498, but as the discussion continued and my ideas started to converge more and more with Eric's, I eventually realised it made more sense as an optional extension to PEP 498 that exposed the inner workings of the scope aware interpolation machinery to Python code. As part of that, I'm +1 on PEP 498's literal string interpolation syntax. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia

On 2015-08-31 9:10 AM, Nick Coghlan wrote:
If PEP 501 is an extension to PEP 498, then the proposal is to add i'' prefix *in addition* to f'', right? If so, I think it might be confusing to a lot of people on what prefix should be used and when. I think it's too easy for an average user to write ``os.system(f'...')`` and think that their code is fine, instead of ``os.system(i'...')``. What's worse, is that there is no way for ``os.system()`` to reject the former use. Second, given that we use "f" for "formatted", using "i" for "interpolated template" is a bit confusing. Can we use "t" ("template strings")? Yury

On 8/31/2015 4:08 PM, Yury Selivanov wrote:
That would be my intention, yes. Your only other choice to get plain strings from a template would be to always say format(i'{expression}'), which I don't think is an improvement.
That's all correct. I have to say that I like PEP 501 mainly for its non-string use cases. That is, interpolators that don't produce strings. Note that this isn't possible with PEP 502's proposal.
I don't really care so much about the prefixes. I'd be okay with PEP 498 being either 'f', 'i', or 't'. I could warm up to 't' easier than 'i'. Eric.

On 8/31/2015 5:07 PM, Eric V. Smith wrote:
Let me rephrase that: with PEP 502, it must be possible to produce a string from every e-string (as they're called there), and since types.ExpressionString derives from str, it's even easier to misuse them as strings and not provide the correct interpolator. This is as opposed to PEP 501, where the equivalent type is not derived from str, and you must call format() or a custom interpolator to get a str. But back to PEP 498: I can't imagine accepting either PEP 501 or 502 without also accepting PEP 498. And once you've accepted 498, are i- or e-strings sufficiently powerful and useful enough, and are they likely to be used in the correct way? I think that's the question. Eric.

On 1 Sep 2015 07:35, "Eric V. Smith" <eric@trueblade.com> wrote:
Exactly, 498 should now be considered independently, with 501 & 502 as potential answers to questions like: * how can we mitigate the increased risk of code injection vulnerabilities that comes with native interpolation support? * how can we handle cases where delaying interpolation would be helpful, like event logging or i18n? * how can we support adaptation of the interpolation syntax to cases like SQL Alchemy's "text" API, which consumes an SQL expression in text form and converts it to SQL Alchemy objects? Writing 501 has satisfied me that those questions *can* be addressed, *if* we decide they should be, and that it can be done in such a way that it can be presented to folks learning Python in the future as an implementation detail of the native string formatting support (that is, folks would be taught formatted strings early, and only later be taught that you can use an interpolation template to split up the template interpolation and template rendering steps. That all adds up to thinking it's fine to defer answering those questions to later, rather than expecting 498 to address them immediately. We have plenty of time until 3.6 rolls around :) Cheers, Nick.
participants (3)
-
Eric V. Smith
-
Nick Coghlan
-
Yury Selivanov