Showing content from http://mail.python.org/pipermail/python-dev/attachments/20150905/4ae8c2f4/attachment-0001.html below:
<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Sat, 5 Sep 2015 at 09:19 Guido van Rossum <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Sep 5, 2015 at 2:10 AM, haypo s <span dir="ltr"><<a href="mailto:victor.stinner@gmail.com" target="_blank">victor.stinner@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span>2015-09-05 5:01 GMT+02:00 Guido van Rossum <<a href="mailto:guido@python.org" target="_blank">guido@python.org</a>>:<br>
</span><span>> And I'm ready to accept it. I'll wait until Tuesday night (Monday's a<br>
> holiday in the US) in case anything unforeseen comes up, but this is really<br>
> the Last Call for this PEP.<br>
<br>
</span>Would it be possible to specify a subset of the Python language<br>
allowed in f-string? For example, __import__ or lambda should not be<br>
used in a f-string. I'm not convinced that a loop or<br>
list/dict/set-comprehension is a good idea neither.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>We already went over this. You might as well argue that __import__ or lambda should not be used as arguments to print(). It's an expression, and it must allow exactly everything that is allowed in other places where expressions are allowed.<br><br></div><div>Of course you don't *have* to write those things in f-string interpolations. But that's just a style guide; the language should not try to second-guess the user.<br></div></div></div></div></blockquote><div><br></div><div>Right, it's the whole "consenting adults" bit along with trying to minimize surprise by placing restrictions that are hard to remember. Having the restriction of "it must be an expression" is pretty minor thing to remember vs. "it must a specific f-string subset of Python as defined in section N.N.N of the language spec". One of those fits in my brain and one of them does not. ;)</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I would prefer to keep as much code as possible *outside* f-string because:<br>
- text editor knows well how to color it<br>
- static analyzers know how to analyze it<br>
- it encourage developers to indent and comment their code correctly,<br>
whereas f-string has more restrictons on indentation</blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Really, we already went over most of this. You can put whitespace (even newlines) exactly where they are allowed in other expressions, as long as they don't terminate the string. You probably shouldn't do any of those things regularly, but there are lots of other things you that you can do in Python that you shouldn't.<br></div></div></div></div></blockquote><div><br></div><div>As Guido said, we're consenting adults and if it makes the code unreadable then don't do it. Just like we promote refactoring code to have more functions to be more readable even though it adds overhead, I suspect we will end up updating PEP 8 to say that f-strings should tend towards simple expressions and should never compromise the readability of the code, in which case the expressions should be hoisted out of the f-string and into the surrounding code.</div><div><br></div><div>I also don't think that we should tie our hands in the design of the language because it makes some work on behalf of the tool providers. If it made it impossible then I think we should discuss it, but simply requiring some more work from tools isn't a sufficient condition to restrict what we do. That's like saying Guido shouldn't have gone with whitespace-delimited formatting because most editors didn't support it back in the day and it took some effort to support it since it wasn't such a simple "find the matching curly brace" algorithm that applied to most languages.</div><div><br></div><div>I appreciate wanting to <i>promote</i>Â making code be readable, I don't think it should come at the <i>cost</i>Â of the simplicity of the solution when coding practices can easily make up for any ugliness that is possible.</div><div><br></div><div>-Brett</div><div>Â </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">(is it possible to indent and comment code inside a f-string?)<br></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div>Now that's an interesting question. I think the answer must be No, because we don't want to deal with ambiguities like whether a closing curly bracket or string quote should be ignored inside such comments. The processing of f-strings described by the PEP uses several phases:<br><br></div><div>- find the end of the string (the final quote[s]) using the same algorithm used for all string literals<br></div><div>- expand \ escapes (e.g. \uXXXX)<br></div><div>- look for single {, then scan ahead to a matching } -- this skips matching () [] {}<br></div><div>- look for optional !a,!r,!s and !<spec> inside each {...} pair<br></div><div>- take what's left, enclose it in (), parse as expression<br><br></div><div>The presence of comments would impede several of these stages.<br></div>Â </div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
For example, for me it's a common practice to write a complex<br>
list-comprehension on two lines for readability:<br>
<br>
newlist = [very_complex_expression(item)<br>
      for item in oldlist]<br>
# sorry, it's hard to indent correctly in a mail client, especially Gmail<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The list comprehension across two lines without the comment would be fine in a triple-quoted f-string (or perhaps even in a single-quoted f-string if you put a \ before the line break).<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Well, I'm not convinced that we need a larger subset than what is<br>
allowed currently in str.format(), simple expressions like: obj.attr,<br>
obj[index], etc.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The PEP explains why actually.<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I recall horrible examples in the previous mail threads showing how<br>
much complex code you can put inside f-string.<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yes, that was a very poorly thought out argument. All of Python should be condemned if you took it seriously.<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Even the following example from the PEP seems too complex to me:<br>
print(f"Usage: {sys.argv[0]} [{'|'.join('--'+opt for opt in<br>
valid_opts)}]", file=sys.stderr)<br>
<br>
Oh, first I read [...] as a list-comprehension :-p But it's part of<br>
the output string, not of the Python code...<br>
<br>
I prefer to build the second parameter outside the f-string:<br>
opts = '|'.join('--'+opt for opt in valid_opts)<br>
print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr)<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>The same criticism can be made for the original version (using .format()), which was lifted from real code.<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
f-string with complex code remembers me PHP where it was possible to<br>
mix PHP and HTML. I have bad memories such... code? template? (I don't<br>
know how to cal them). Text editors and me were unable to identify<br>
quickly the beginning and end of the code. We have a similar issue<br>
with Python unit test embedding Python code to run subprocesses. My<br>
text editor vim is unable to identify if the current code is the<br>
outter code or the code embedded in a long triple-quoted string<br>
(especially when you open the file at the embedded code).<br></blockquote><div><br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yeah, tools will need to be updated. There are several other languages (e.g. Ruby) that allow arbitrary expressions in strings and at least some editors have no problem with them, even vim.<br></div><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Maybe we should start with a simple f-string, play with it during one<br>
cycle (Python 3.6), and then discuss again if it's necessary to extend<br>
the allowed Python expresions inside f-string?<br>
<br>
If you really want to allow *any* Python inside a f-string, can you<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
please at least explain in the PEP why you consider that it's a good<br>
thing?<br></blockquote><div><br></div><div>Sigh. We've gone over this on python-ideas. Your objection is not new.<br></div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Â </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
IMHO the main advantage of allowing expressions inside f-string is<br>
that it adds something really new compared to the current str.format()<br>
method. Without it, f-string are less interesting.<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra">-- <br><div>--Guido van Rossum (<a href="http://python.org/~guido" target="_blank">python.org/~guido</a>)</div>
</div></div>
_______________________________________________<br>
Python-Dev mailing list<br>
<a href="mailto:Python-Dev@python.org" target="_blank">Python-Dev@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-dev" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-dev</a><br>
Unsubscribe: <a href="https://mail.python.org/mailman/options/python-dev/brett%40python.org" rel="noreferrer" target="_blank">https://mail.python.org/mailman/options/python-dev/brett%40python.org</a><br>
</blockquote></div></div>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4