(original) (raw)

Hi,

I'd like to collect thinking on best practices that we can use as a style guide for string interpolation. Now that arbitrary expressions are very likely to be included, it is more important to set guidelines than it would otherwise be.

Below is a recent post with some good ideas (though it hopes to restrict expressions, which is not what we're discussing here, but rather creation of a style-guide for code-review a la PEP8).

Would anyone else like to contribute?

\-Mike

Recent posts:

\- On PEPs to augment PEP8:

https://mail.python.org/pipermail/python-dev/2015-September/141473.html

\- On things to avoid in f-strings:

https://mail.python.org/pipermail/python-dev/2015-September/141451.html
(part included below)


On 09/05/2015 02:10 AM, haypo s (Victor Stinner) wrote:
\> Would it be possible to specify a subset of the Python language
\> allowed in f-string? For example, \_\_import\_\_ or lambda should not be
\> used in a f-string. I'm not convinced that a loop or
\> list/dict/set-comprehension is a good idea neither.
\>
\> I would prefer to keep as much code as possible \*outside\* f-string because:
\> - text editor knows well how to color it
\> - static analyzers know how to analyze it
\> - it encourage developers to indent and comment their code correctly,
\> whereas f-string has more restrictons on indentation (is it possible
\> to indent and comment code inside a f-string?)
\>
\> For example, for me it's a common practice to write a complex
\> list-comprehension on two lines for readability:
\>
\> newlist = \[very\_complex\_expression(item)
\> for item in oldlist\]
\> # sorry, it's hard to indent correctly in a mail client, especially Gmail
\>
\> Well, I'm not convinced that we need a larger subset than what is
\> allowed currently in str.format(), simple expressions like: obj.attr,
\> obj\[index\], etc.
\>
\> I recall horrible examples in the previous mail threads showing how
\> much complex code you can put inside f-string.
\>
\> Even the following example from the PEP seems too complex to me:
\> print(f"Usage: {sys.argv\[0\]} \[{'|'.join('--'+opt for opt in
\> valid\_opts)}\]", file=sys.stderr)
\>
\> Oh, first I read \[...\] as a list-comprehension :-p But it's part of
\> the output string, not of the Python code...
\>
\> I prefer to build the second parameter outside the f-string:
\> opts = '|'.join('--'+opt for opt in valid\_opts)
\> print(f"Usage: {sys.argv\[0\]} \[{opts}\]", file=sys.stderr)
\>
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org