PEP8 dictionary indenting addition
I have an idea to improve indenting guidelines for dictionaries for better readability: If a value in a dictionary literal is placed on a new line, it should have (or at least be allowed to have) a n additional hanging indent. Below is an example: mydict = {'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': 'a very very very ' 'long value that continues on the next line', } As opposed to this IMHO much less readable version: mydict = {'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': 'a very very very ' 'long value that continues on the next line', } As you can see it is much harder in the second version to distinguish between keys and values.
On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
Looks good to me, except that my personal preference for the implicit string concatenation (thirdkey) is to move the space to the following line, and (if possible) align the parts: mydict = {'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': 'a very very very' ' long value that continues on the next line', } (And also align the closing brace with the opening brace.) Really long lines like thirdkey are ugly no matter what you do, but I find that the leading space stands out more than the trailing space, and makes it more obvious that something out of the ordinary is going on. Very few string literals start with a leading space, so when I see one, I know to look more closely. In your example, I find that I don't even notice the trailing space unless I read the string very carefully. -- Steve
On 9 October 2016 at 01:25, Steven D'Aprano <steve@pearwood.info> wrote:
The proposed approach looks good to me, but I'm a strong believe that when you get to situations this complex, the overriding rule should always be "use your judgement". For thirdkey, it's quite possible I'd advise splitting the value out into a named variable. I'd probably lay this out as # Less indent needed for keys, so thirdkey fits better in this case mydict = { 'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': 'a very very very long value that continues on the next line', } Or # Move the troublesome value out into a named variable val3 = 'a very very very long value that continues on the next line' mydict = { 'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': val3, } or if I *really* had to split val3, I might go for # Triple-quote/backslash lets you start at the left margin. # And I personally find space-backslash more noticeable than space-quote # Space on the second line is often semantically less consistent (depends on the value) val3 = '''\ a very very very long value that \ continues on the next line''' or even # Just give up on trying to make it a constant val3 = ' '.join([ "a very very very long value that", "continues on the next line" ]) There's also the option of simply giving up on the line length guideline for this one value, and putting the constant on one long line. Lots of possibilities, and which one I'd go for depends on context and the actual content of a (non-toy) example. Paul
On 09/10/16 12:43, Paul Moore wrote:
+1 from me on this general style of layout. Why associate the indentation level with the name of the identifier being bound? Treat the opening parenthesis as beginning a "suite" of indented key/value pairs in the same way as a colon introduces an indented suite of statements in other constructs. It may not be part of the formal syntax, but it's consistent with other constructs in the language that _are_ defined by the formal syntax. E.
On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Heh--not to bikeshed, but my personal preference is to leave the trailing space on the first line. This is because by the time I've started a new line (and possibly have spent time fussing with indentation for the odd cases that my editor doesn't get quite right) I'll have forgotten that I need to start the line with a space :) Best, Erik
On Oct 11, 2016 10:40 AM, "Erik Bray" <erik.m.bray@gmail.com> wrote:
On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano <steve@pearwood.info>
wrote: line, it
Until you end up with like 20 merge conflicts because some editors strip trailing whitespace...
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
On 10/11/2016 12:08 PM, Ryan Gonzalez wrote:
I agree that the first version of the example, with space after 'very', before the quote, is better. I also put '\n' at the end of literals to be auto-joined, rather than at the beginning.
Until you end up with like 20 merge conflicts because some editors strip trailing whitespace...
A space within a string literal is not trailing whitespace and will not be stripped. -- Terry Jan Reedy
On Tue, Oct 11, 2016 at 10:24:47PM -0400, Terry Reedy wrote:
I used to think the same, until I got sick and tired of having my code output strings like: a very very verylong value that continues on the next line I learned the hard way that if I don't put the breaking space at the beginning of the next fragment, I probably wouldn't put it at the end of the previous fragment either. YMMV, I'm just reporting what works for me. -- Steve
Steven D'Aprano writes:
The converse applies in my case, so that actually doesn't matter to me. When I don't put it in, I don't put it in anywhere. What does matter to me is that I rarely make spelling errors (including typos) or omit internal spaces. That means I can get away with not reading strings carefully most of the time, and I don't. But omitted space at the joins of a continued string is frequent, and frequently caught when I'm following skimming down a suite to the next syntactic construct. But spaces at end never will be. Ie, space-at-beginning makes for more effective review for me. YMMV.
Terry Reedy writes:
On 10/12/2016 1:40 PM, Stephen J. Turnbull wrote:
Ie, space-at-beginning makes for more effective review for me. YMMV.
I think that PEP 8 should not recommend either way.
Oops, sorry, I forgot that was what we were talking about (subject notwithstanding. :-( I told you I don't read strings!) Is there room in PEP 8 for mention of pros and cons in "YMMV" cases? Steve
On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:
Looks good to me, except that my personal preference for the implicit string concatenation (thirdkey) is to move the space to the following line, and (if possible) align the parts: mydict = {'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': 'a very very very' ' long value that continues on the next line', } (And also align the closing brace with the opening brace.) Really long lines like thirdkey are ugly no matter what you do, but I find that the leading space stands out more than the trailing space, and makes it more obvious that something out of the ordinary is going on. Very few string literals start with a leading space, so when I see one, I know to look more closely. In your example, I find that I don't even notice the trailing space unless I read the string very carefully. -- Steve
On 9 October 2016 at 01:25, Steven D'Aprano <steve@pearwood.info> wrote:
The proposed approach looks good to me, but I'm a strong believe that when you get to situations this complex, the overriding rule should always be "use your judgement". For thirdkey, it's quite possible I'd advise splitting the value out into a named variable. I'd probably lay this out as # Less indent needed for keys, so thirdkey fits better in this case mydict = { 'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': 'a very very very long value that continues on the next line', } Or # Move the troublesome value out into a named variable val3 = 'a very very very long value that continues on the next line' mydict = { 'mykey': 'a very very very very very long value', 'secondkey': 'a short value', 'thirdkey': val3, } or if I *really* had to split val3, I might go for # Triple-quote/backslash lets you start at the left margin. # And I personally find space-backslash more noticeable than space-quote # Space on the second line is often semantically less consistent (depends on the value) val3 = '''\ a very very very long value that \ continues on the next line''' or even # Just give up on trying to make it a constant val3 = ' '.join([ "a very very very long value that", "continues on the next line" ]) There's also the option of simply giving up on the line length guideline for this one value, and putting the constant on one long line. Lots of possibilities, and which one I'd go for depends on context and the actual content of a (non-toy) example. Paul
On 09/10/16 12:43, Paul Moore wrote:
+1 from me on this general style of layout. Why associate the indentation level with the name of the identifier being bound? Treat the opening parenthesis as beginning a "suite" of indented key/value pairs in the same way as a colon introduces an indented suite of statements in other constructs. It may not be part of the formal syntax, but it's consistent with other constructs in the language that _are_ defined by the formal syntax. E.
On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano <steve@pearwood.info> wrote:
Heh--not to bikeshed, but my personal preference is to leave the trailing space on the first line. This is because by the time I've started a new line (and possibly have spent time fussing with indentation for the odd cases that my editor doesn't get quite right) I'll have forgotten that I need to start the line with a space :) Best, Erik
On Oct 11, 2016 10:40 AM, "Erik Bray" <erik.m.bray@gmail.com> wrote:
On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano <steve@pearwood.info>
wrote: line, it
Until you end up with like 20 merge conflicts because some editors strip trailing whitespace...
-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/
On 10/11/2016 12:08 PM, Ryan Gonzalez wrote:
I agree that the first version of the example, with space after 'very', before the quote, is better. I also put '\n' at the end of literals to be auto-joined, rather than at the beginning.
Until you end up with like 20 merge conflicts because some editors strip trailing whitespace...
A space within a string literal is not trailing whitespace and will not be stripped. -- Terry Jan Reedy
On Tue, Oct 11, 2016 at 10:24:47PM -0400, Terry Reedy wrote:
I used to think the same, until I got sick and tired of having my code output strings like: a very very verylong value that continues on the next line I learned the hard way that if I don't put the breaking space at the beginning of the next fragment, I probably wouldn't put it at the end of the previous fragment either. YMMV, I'm just reporting what works for me. -- Steve
Steven D'Aprano writes:
The converse applies in my case, so that actually doesn't matter to me. When I don't put it in, I don't put it in anywhere. What does matter to me is that I rarely make spelling errors (including typos) or omit internal spaces. That means I can get away with not reading strings carefully most of the time, and I don't. But omitted space at the joins of a continued string is frequent, and frequently caught when I'm following skimming down a suite to the next syntactic construct. But spaces at end never will be. Ie, space-at-beginning makes for more effective review for me. YMMV.
Terry Reedy writes:
On 10/12/2016 1:40 PM, Stephen J. Turnbull wrote:
Ie, space-at-beginning makes for more effective review for me. YMMV.
I think that PEP 8 should not recommend either way.
Oops, sorry, I forgot that was what we were talking about (subject notwithstanding. :-( I told you I don't read strings!) Is there room in PEP 8 for mention of pros and cons in "YMMV" cases? Steve
participants (9)
-
Erik -
Erik Bray -
Guido van Rossum -
Jelte Fennema -
Paul Moore -
Ryan Gonzalez -
Stephen J. Turnbull -
Steven D'Aprano -
Terry Reedy