[Python-ideas] Draft PEP on string interpolation

[Eric V. Smith]

On 08/24/2015 07:55 PM, Andrew Barnert wrote:
> On Aug 24, 2015, at 08:14, Eric V. Smith <eric at trueblade.com> wrote:
>>
>>> On 08/23/2015 09:13 PM, Guido van Rossum wrote:
>>> But for i-strings, I think it would be good if we could gather more
>>> actual experience using them. Every potential use case brought up for
>>> these so far (translation, html/shell/sql quoting) feels like there's a
>>> lot of work needing to be done to see if the idea is actually viable
>>> there. It would be a shame if we added all the (considerable!) machinery
>>> for i-strings and all we got was yet another way to do it
>>> (https://xkcd.com/927/), without killing at least one competing approach
>>> (similar to the way .format() has failed to replace %).
>>>
>>> It's tough to envision how we could gather more experience with
>>> i-strings *without* building them into the language, but I'm really
>>> hesitant to add them without more experience. (This is the "new on the
>>> job market" paradox. :-) Maybe they could be emulated using a function
>>> call that uses sys._getframe() under the covers? Or maybe it's possible
>>> to cook up an experiment using other syntax hooks? E.g. the coding hack
>>> used in pyxl (https://github.com/dropbox/pyxl).[1]
>>
>>
>> I hope you don't mind that I borrowed the keys to the time machine. I'm
>> using the implementation of _string.formatter_parser() that I added for
>> implementing string.Formatter:
> 
> Nifty! When I get a chance, I'll slap this together with an import hook using the untokenize hack, so I can actually play with i-strings (and f-strings) with the proposed syntax without needing a patch. If it looks good, I can write a real implementation that doesn't have all the untokenize problems, which could also eliminate the need for _getframe. (To make it backportable to 3.3/2.7 we'd still need to backport formatter_parser, right? But that still seems like something that could be done and posted on PyPI.)

I don't know what the untokenize problems are, so I'm not sure I can
help there.

I also don't think I'd base any real implementation on
_string.formatted_parser: it won't be terribly efficient. I've created a
project on bitbucket: https://bitbucket.org/ericvsmith/istring where I'm
playing with a "join" method and a callback interface, without ever
exposing the looping and parsing to the caller. I think that would be a
better interface than an iterator exposing the various parts of the string.

But, as Guido suggests above, it's all just an academic exercise to
understand how to best use i-strings. I suggest providing feedback on
their API before implementing anything more serious.

Eric.