[Python-Dev] String Interpolation Best Practices (original) (raw)
Guido van Rossum guido at python.org
Tue Sep 8 19:32:02 CEST 2015
- Previous message (by thread): [Python-Dev] String Interpolation Best Practices
- Next message (by thread): [Python-Dev] String Interpolation Best Practices
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Sounds awfully premature. Style guides are typically updated in response to the occurrence of bad practice in the wild, not in anticipation of such bad practice. I would give the users of Python 3.6 some more credit.
On Tue, Sep 8, 2015 at 12:17 AM, Mike Miller <python-dev at mgmiller.net> wrote:
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 = [verycomplexexpression(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 > validopts)}]", 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 validopts) > print(f"Usage: {sys.argv[0]} [{opts}]", file=sys.stderr) >
Python-Dev mailing list Python-Dev at python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (python.org/~guido) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20150908/112ec767/attachment.html>
- Previous message (by thread): [Python-Dev] String Interpolation Best Practices
- Next message (by thread): [Python-Dev] String Interpolation Best Practices
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]