<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Aug 22, 2015 at 1:36 PM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.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 23 August 2015 at 02:16, Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br>
> On Sat, Aug 22, 2015 at 3:09 AM, Nick Coghlan <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
</span><span class="">>> (Similar to yield, it is proposed that interpolation expressions would<br>
>> require parentheses when embedded inside a larger expression)<br>
><br>
><br>
> 1. That's an entirely different proposal, you're just reusing the PEP<br>
> number.<br>
<br>
</span>It's aiming to solve the same basic problem though, which is the<br>
aspect I consider most important when tackling a design question. The<br>
discussions following the posting of my first draft highlighted some<br>
real limitations of my original design both at a semantic level and at<br>
a motivational level, so I changed it in place rather than introducing<br>
yet another PEP on the same topic (Mike Miller's draft PEP was an<br>
excellent synthesis, but there's no way he could account for the fact<br>
that 501 was still only a first draft).<span class=""><br></span></blockquote><div><br></div><div>Yeah, it's not unheard of for PEP authors to pivot after listening to feedback. :-)<br><br>OTOH this topic is rich enough that I have no problem spending a few more PEP numbers on it. If Mike asks for a PEP number I am not going to withhold it.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
> 2.  Have I died and gone to Perl?<br>
<br>
</span>That's my question in relation to PEP 498 - it seems to introduce lots<br>
of line noise for people to learn to read for little to no benefit (my<br>
perspective is heavily influenced by the fact that most of the code I<br>
write myself these days consists of network API calls + logging<br>
messages + UI template rendering, with only very occasional direct<br>
calls to str.format that use anything more complicated than "{}" or<br>
"{!r}" as the substitution field).<br>
<br>
As a result, I'd be a lot more comfortable with PEP 498 if it had more<br>
examples of potential practical use cases, akin to the examples<br>
section from PEP 343 for context managers.<br></blockquote><div><br></div><div>Since you accept "!r", you must be asking about the motivation for including ":spec", right? That's inherited from PEP 3101. For myself, I know that the most common use of format specs is to limit the number of digits printed for floating point numbers, e.g.<br><br></div><div>  t0 = time.time()<br></div><div>  chop_onions(n)<br></div><div>  t1 = time.time()<br></div><div>  print("Chopped %d onions in %.3f seconds." % (n, t1-t0))<br><br></div><div>Or, using PEP 3101,<br><br></div><div>  print("Chopped {} onions in {:.3f} seconds.".format(n, t1-t0))<br></div><div><br></div><div>Using the PEP 498 I can write this as<br></div><div><br></div><div>  print("Chopped {n} onions in {t1-t0:.3f} seconds.")<br><br></div><div>But in PEP 498 without :spec, I'd have to find some other way of formatting t1-t0, and none of the alternatives look pretty. (Anything that requires introducing a temporary variable feels particularly ugly to me.)<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
While the second draft of PEP 501 is even more line-noisy than PEP 498<br>
due to the use of both "!" and "$", it at least generalises the<br>
underlying semantics of compiler-assisted interpolation to apply to<br>
additional use cases like logging, i18n (including compatibility<br>
with Mozilla's l20n syntax), safe SQL interpolation, safe shell<br>
command interpolation, HTML template rendering, etc.<br></blockquote><div><br></div><div>That's perhaps a bit *too* ambitious. The claim of "safety" for PEP 498 is simple -- it does not provide a way for a dynamically generated string to access values in the current scope (and it does this by not supporting dynamically generated strings). For most  domains you mention, safety is much more complex, and in fact mostly orthogonal -- code injection attacks rely on the value of the interpolated variables, so PEP 498's "safety" does not help at all. I18n safety may be the exception -- the scenario is an untrustworthy translator who adds an interpolation that references a variable whose content is deemed sensitive, perhaps a database key.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For the third draft, I'll take another pass at the surface syntax - I<br>
like the currently proposed semantics, but agree the current spelling<br>
is overly sigil heavy.<br></blockquote></div><br></div><div class="gmail_extra">Good luck.<br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature">--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>