Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Indent dictionary values on a new line extra #61

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

JelteF
Copy link
Contributor

@JelteF JelteF commented Oct 6, 2016

This indents dictionaries in the following way:

mydict = {"12345":
              'abcde'}

let res = base + s:sw() * 2
endif

" If a colon is the final charactar on previous line
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

s/charactar/character/
Also mention that this is for dicts here?

@blueyed
Copy link
Member

blueyed commented Oct 6, 2016

I like it. Do you have some reference, e.g. is it mentioned in PEP8?

Current behavior:

mydict = {"12345":
          'abcde'}

@myint
Copy link

myint commented Oct 7, 2016

I'm not sure about PEP 8, but pycodestyle will complain about this.

test.py:2:15: E127 continuation line over-indented for visual indent

@JelteF
Copy link
Contributor Author

JelteF commented Oct 8, 2016

@blueyed, I like it as well, so much in fact that I assumed it would be allowed by PEP8. But as @myint notes it is indeed marked as wrong by pycodestyle. Looking at PEP8 itself it is not special cased and not even allowed. Because I think this indentation is much clearer I just sent the following to the python-ideas mailinglist:

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.

@JelteF JelteF force-pushed the indent-dictionary-values-extra branch from be5bd7d to 42b2305 Compare October 8, 2016 19:50
@blueyed
Copy link
Member

blueyed commented Oct 8, 2016

For reference: Guido likes it: https://mail.python.org/pipermail/python-ideas/2016-October/042754.html.

@JelteF
Copy link
Contributor Author

JelteF commented Oct 9, 2016

I made a pull request in the peps repo: python/peps#113
To make clear the current changes I made, do not actually create the example code shown there, only partly.

@blueyed blueyed force-pushed the indent-dictionary-values-extra branch from 42b2305 to d19b456 Compare July 26, 2018 09:20
@codecov
Copy link

codecov bot commented Jul 26, 2018

Codecov Report

Merging #61 into master will increase coverage by 0.06%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #61      +/-   ##
==========================================
+ Coverage   92.75%   92.82%   +0.06%     
==========================================
  Files           1        1              
  Lines         207      209       +2     
==========================================
+ Hits          192      194       +2     
  Misses         15       15
Impacted Files Coverage Δ
indent/python.vim 92.82% <100%> (+0.06%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d9efc96...d19b456. Read the comment docs.

@blueyed
Copy link
Member

blueyed commented Jul 26, 2018

I've rebased this.

We might add a configuration variable for it though, since it will trigger flake8/pycodestyle's E127, which might be annoying.

I've created PyCQA/pycodestyle#785 to ask for relaxation of this in pycodestyle itself.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants