On Fri, Aug 19, 2016 at 1:43 PM, Eric V. Smith <e...@trueblade.com> wrote:
>
>
> With your proposal, it's much more difficult to find the end of an
> f-string. I do not think this is a reasonable requirement.
>
> For example, consider the following:
> f'a{func({'a{':1,'3}':[{}, ')', '{']})}b'
>
> A regex will not be able to deal with the matching braces needed to
> find the end of the expression. You need to keep track of the nesting
> level of parens, braces, brackets, and quotes (at least those, I might
> have left something off).
>
> The way this currently is written in Python 3.6a4:
> f"a{func({'a{':1,'3}':[{}, ')', '{']})}b"
>
> It's trivially easy to find the end of the string. It's easy for both
> humans and the parsers.
>It might be harder to find the end of an f-string in one shot, but I think that's the crux of the issue: to a reader/developer, is an f-string conceptually one thing or a compound thing? To me (someone who would like to see f-string expressions appear like normal expressions, without extra quoting, and proper syntax highlighting *always*, just like shell), this argument is essentially the same as trying to use a regex to find a closing bracket or brace or parse HTML. It's only hard (disregarding any underlying impl details) because that view regards f-strings as singular things with only one "end", when in reality an f-string is much much more like a compound expression that just happens to look like a string. If one rejects the notion that an f-string is "one thing", the boundaries can then be defined as either an unescaped closing quote an unescaped opening curly brace. When that boundary is met, the highlighter switches to normal python syntax parsing just like it would have at the real end of the string. It also starts looking for a closing curly brace to denote the start of "another" string. There is a difference however in that f-string "expressions" also support format specifications. These are not proper Python expressions to begin with so they don't have any existing highlights. Not sure what they should look like I really think it should. Please look at python code with f-literals. if >> they’re highlighted as strings throughout, you won’t be able to spot >> which parts are code. if they’re highlighted as code, the escaping rules >> guarantee that most highlighters can’t correctly highlight python >> anymore. i think that’s a big issue for readability. >> > > Maybe I'm the odd man out, but I really don't care if my editor ever > syntax highlights within f-strings. I don't plan on putting anything more > complicated than variable names in my f-strings, and I think PEP 8 should > recommend something similar. > If things aren't highlighted properly I can't see them very well. If f-strings look like other strings in my editor I will absolutely gloss over them as normal strings, expecting no magic, until I later realize some other way. Since I spend significant amounts of time reading foreign code I could see this being quite obnoxious. It might be sufficient to highlight the entire f-string a different color, but honestly I don't think an f-string should ever ever... ever misrepresent itself as a "string", because it's not. It's code that outputs a string, in a compact and concise way. Proper syntax highlighting is one of the most important things in my day-to-day development. I loved the idea of f-strings when they were discussed previously, but I haven't used them yet. If they hide what they really doing under the guise of being a string, I personally will use them much less, despite wanting to, and understanding their value. When I look at a string I want to immediately know just how literal it really is.
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
