<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Aug 10, 2015 at 8:49 PM, Eric V. Smith <span dir="ltr"><<a href="mailto:eric@trueblade.com" target="_blank">eric@trueblade.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 08/10/2015 02:44 PM, Yury Selivanov wrote:<br>
> On 2015-08-10 2:37 PM, Eric V. Smith wrote:<br>
>> This is why I think PEP-498 isn't the solution for i18n. I'd really like<br>
>> to be able to say, in a debugging context:<br>
>><br>
>> print('a:{self.a} b:{self.b} c:{self.c} d:{self.d}')<br>
>><br>
>> without having to create locals to hold these 4 values.<br>
><br>
> Why can't we restrict expressions in f-strings to<br>
> attribute/item getters?<br>
><br>
> I.e. allow f'{foo.bar.baz}' and f'{self.foo["bar"]}' but<br>
> disallow f'{foo.bar(baz=something)}'<br>
<br>
</span>It's possible. But my point is that Barry doesn't even want<br>
attribute/item getters for an i18n solution, and I'm not willing to<br>
restrict it that much.</blockquote><div><br></div><div>I also don't want to tie this closely to i18n. That is (still) very much a wold of its own.<br><br></div><div>What I want with f-strings (by any name) is a way to generalize from print() calls with multiple arguments. We can write<br><br></div><div><span style="font-family:monospace,monospace">  print('Todo:', len(self.todo), '; busy:', len(self.busy))</span><br><br></div><div>but the same thing is more awkward when you have to pass it as a single string to a function that just sends one string somewhere. And note that the above example inserts a space before the ';' which I don't really like. So it would be nice if instead we could write<br><br></div><div><span style="font-family:monospace,monospace">  print(f'Todo: {len(self.todo)}; busy: {len(self.busy)}')</span><br><br></div><div>which IMO is just as readable as the multi-arg print() call[1], and generalizes to other functions besides print().<br><br>In fact, the latter form has less punctuation noise than the former -- every time you insert an expression in a print() call, you have a quote+comma before it and a comma+quote after it, compared to a brace before and one after in the new form. (Note that this is an argument for using f'{...}' rather than '\{...}' -- for a single interpolation it's the same amount of typing, but for multiple interpolations, f'{...}{...}' is actually shorter than '\{...}\{...}', and also the \{ part is ugly.)<br><br></div><div>Anyway, this generalization from print() is why I want arbitrary expressions. Wouldn't it be silly if we introduced print() today and said "we don't really like to encourage printing complicated expressions, but maybe we can introduce them in a future version"... :-)<br><br></div><div>Continuing the print()-generalization theme, if things become too long to fit on a line we can write<br><br></div><div><span style="font-family:monospace,monospace">  print('Todo:', len(self.todo),<br></span></div><div><span style="font-family:monospace,monospace">        '; busy:', len(self.busy))</span><br><br></div><div>Can we allow the same in f-strings? E.g.<br><br></div><div><span style="font-family:monospace,monospace">  print(f'Todo: {len(self.todo)<br></span></div><div><span style="font-family:monospace,monospace">        }; busy: {len(self.busy)<br>        }')</span><br><br></div><div>or is that too ugly? It could also be solved using implicit concatenation, e.g.<br><br></div><div><span style="font-family:monospace,monospace">  print(f'Todo: {len(self.todo)}; '<br></span></div><div><span style="font-family:monospace,monospace">        f'busy: {len(self.busy)}')</span><br></div><div><br></div><div>[1] Assuming syntax colorizers catch on.<br></div></div><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>