On 08/24/2015 07:55 PM, Andrew Barnert wrote:

On Aug 24, 2015, at 08:14, Eric V. Smith <eric@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.