<p dir="ltr"><br>
</p>
<p dir="ltr"></p>
<p dir="ltr">On Sun, Aug 9, 2015, 13:51 Peter Ludemann via Python-Dev <<a href="mailto:python-dev@python.org">python-dev@python.org</a>> wrote:</p>
<blockquote><p dir="ltr">Most of my outputs are log messages, so this proposal won't help me because (I presume) it does eager evaluation of the format string and the logging methods are designed to do lazy evaluation. Python doesn't have anything like Lisp's "special forms", so there doesn't seem to be a way to implicitly put a lambda on the string to delay evaluation.<br></p>
<p dir="ltr">It would be nice to be able to mark the formatting as lazy ... maybe another string prefix character to indicate that? (And would the 2nd expression in an assert statement be lazy or eager?)</p>
</blockquote>
<p dir="ltr"><br></p>
<p dir="ltr">That would require a lazy string type which is beyond the scope of this PEP as proposed since it would require its own design choices, how much code would not like the different type, etc.</p>
<p dir="ltr">-Brett</p>
<blockquote><p dir="ltr"><br></p>
<p dir="ltr">PS: As to Brett's comment about the history of string interpolation ... my recollection/understanding is that it started with Unix shells and the "$variable" notation, with the "$variable" being evaluated within "..." and not within '...'. Perl, PHP, Make (and others) picked this up. There seems to be a trend to avoid the bare "$variable" form and instead use "${variable}" everywhere, mainly because "${...}" is sometimes required to avoid ambiguities (e.g. "There were $NUMBER ${THING}s.")<br></p>
<p dir="ltr">PPS: For anyone wishing to improve the existing format options, Common Lisp's <a href="http://www.gigamonkeys.com/book/a-few-format-recipes.html">FORMAT</a> and Prolog's <a href="https://quintus.sics.se/isl/quintus/html/quintus/mpg-ref-format.html">format/2</a> have some capabilities that I miss from time to time in Python.<br></p>
<p dir="ltr">On 9 August 2015 at 11:22, Eric V. Smith <<a href="mailto:eric@trueblade.com">eric@trueblade.com</a>> wrote:</p>
</blockquote>
<blockquote><blockquote><p dir="ltr">On 8/9/2015 1:38 PM, Brett Cannon wrote:<br>
><br>
><br>
> On Sun, 9 Aug 2015 at 01:07 Stefan Behnel <<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a></p>
<p dir="ltr">> <mailto:<a href="mailto:stefan_ml@behnel.de">stefan_ml@behnel.de</a>>> wrote:<br>
><br>
> Eric V. Smith schrieb am 08.08.2015 um 03:39:<br>
> > Following a long discussion on python-ideas, I've posted my draft of<br>
> > PEP-498. It describes the "f-string" approach that was the subject of<br>
> > the "Briefer string format" thread. I'm open to a better title than<br>
> > "Literal String Formatting".<br>
> ><br>
> > I need to add some text to the discussion section, but I think it's in<br>
> > reasonable shape. I have a fully working implementation that I'll get<br>
> > around to posting somewhere this weekend.<br>
> ><br>
> > >>> def how_awesome(): return 'very'<br>
> > ...<br>
> > >>> f'f-strings are {how_awesome()} awesome!'<br>
> > 'f-strings are very awesome!'<br>
> ><br>
> > I'm open to any suggestions to improve the PEP. Thanks for your<br>
> feedback.<br>
><br>
> [copying my comment from python-ideas here]<br>
><br>
> How common is this use case, really? Almost all of the string formatting<br>
> that I've used lately is either for logging (no help from this proposal<br>
> here) or requires some kind of translation/i18n *before* the formatting,<br>
> which is not helped by this proposal either. Meaning, in almost all<br>
> cases,<br>
> the formatting will use some more or less simple variant of this<br>
> pattern:<br>
><br>
> result = process("string with {a} and {b}").format(a=1, b=2)<br>
><br>
> which commonly collapses into<br>
><br>
> result = translate("string with {a} and {b}", a=1, b=2)<br>
><br>
> by wrapping the concrete use cases in appropriate helper functions.<br>
><br>
> I've seen Nick Coghlan's proposal for an implementation backed by a<br>
> global<br>
> function, which would at least catch some of these use cases. But it<br>
> otherwise seems to me that this is a huge sledge hammer solution for a<br>
> niche problem.<br>
><br>
><br>
> So in my case the vast majority of calls to str.format could be replaced<br>
> with an f-string. I would also like to believe that other languages that<br>
> have adopted this approach to string interpolation did so with knowledge<br>
> that it would be worth it (but then again I don't really know how other<br>
> languages are developed so this might just be a hope that other<br>
> languages fret as much as we do about stuff).</p>
<p dir="ltr">I think it has to do with the nature of the programs that people write.<br>
I write software for internal use in a large company. In the last 13<br>
years there, I've written literally hundreds of individual programs,<br>
large and small. I just checked: literally 100% of my calls to<br>
%-formatting (older code) or str.format (in newer code) could be<br>
replaced with f-strings. And I think every such use would be an improvement.</p>
<p dir="ltr">I firmly believe that the majority of software written in Python does<br>
not show up on PyPi, but is used internally in corporations. It's not<br>
internationalized or localized: it just exists to get a job done<br>
quickly. This is the code that would benefit from f-strings.</p>
<p dir="ltr">This isn't to say that there's not plenty of code where f-strings would<br>
not help. But I think it's as big a mistake to generalize from my<br>
experience as it is from Stefan's.</p>
<p dir="ltr"><font color="#888888">Eric.</font><br>
</p>
</blockquote>
</blockquote>
<blockquote><p dir="ltr"><br>
</p>
</blockquote>
<blockquote><blockquote><p dir="ltr"><br>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
</p>
</blockquote>
</blockquote>
<blockquote><p dir="ltr"><br>
</p>
</blockquote>
<blockquote><blockquote><p dir="ltr">Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/pludemann%40google.com">https://mail.python.org/mailman/options/python-dev/pludemann%40google.com</a><br>
</p>
</blockquote>
</blockquote>
<blockquote><p dir="ltr"></p>
<p dir="ltr">_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</p>
</blockquote>
<p dir="ltr"><br>
</p>