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/archive%40mail-archive.com
