Might also send something to pystylechecker at the same time. --Guido (mobile) On Oct 8, 2016 1:23 PM, "Jelte Fennema" wrote:

Alright, I'll make one when I have some time in the near future.

On 8 Oct 2016 10:08 pm, "Guido van Rossum" wrote:

...

Makes sense, maybe you can send a PR to the Python/peps repo?

--Guido (mobile)

On Oct 8, 2016 12:27 PM, "Jelte Fennema" wrote:

...

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.

_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/

On 9 October 2016 at 01:25, Steven D'Aprano wrote:

On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:

...

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', }

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:

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 Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano wrote:

On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:

...

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', }

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', }

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 10/11/2016 12:08 PM, Ryan Gonzalez wrote:

On Oct 11, 2016 10:40 AM, "Erik Bray" mailto:erik.m.bray@gmail.com> wrote:

...

On Sun, Oct 9, 2016 at 2:25 AM, Steven D'Aprano

...

...

On Sat, Oct 08, 2016 at 09:26:13PM +0200, Jelte Fennema wrote:

...

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

mailto:steve@pearwood.info> wrote: 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', }

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', }

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 :)

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

Steven D'Aprano writes:

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.

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