PEP8: Dictionary values should have an extra indent #113
Conversation
|
Hello, and thanks for your contribution! Unfortunately we couldn't find an account corresponding to your GitHub username at bugs.python.org (b.p.o). If you don't already have an account at b.p.o, please create one and make sure to add your GitHub username. If you do already have an account at b.p.o then please go there and under "Your Details" add your GitHub username. And in case you haven't already, please make sure to sign the PSF contributor agreement (CLA); we can't legally look at your contribution until you have signed the CLA. Once you have done everything that's needed, please reply here and someone will verify everything is in order. |
|
Done |
JelteF
force-pushed
the
pep8-dict-indent
branch
from
31853bb
to
8a77804
Compare
|
|
||
| Yes:: | ||
|
|
||
| # Keys alligned with opening delimiter, values have an extra indent |
There was a problem hiding this comment.
s/alligned/aligned/
Add a dot at the end (also below).
| ' and even on the line after that.', | ||
| } | ||
|
|
||
| # Keys one and values with two hanging indents |
There was a problem hiding this comment.
s/one/with one/
s/hanging/levels of hanging/?
JelteF
force-pushed
the
pep8-dict-indent
branch
from
8a77804
to
6890a16
Compare
|
Thanks for the contribution! I'm not sure we need to add this to PEP 8 though. IME it's a relatively rare occurrence, and I think we should leave it up to local conventions on how to deal with it. For example, if I was code reviewing some of the given examples, I'd probably ask for a refactoring where such long, multiline strings were assigned to local or globals and only the variable names added as values to the dict literal. Do you know of any situations in the stdlib where readability is affected by this problem? I'd like to look at actual motivating examples to see whether this was a common enough problem to benefit from adding more guidelines to PEP 8. |
| 'firstkey': | ||
| 'a very very very very very long value', | ||
| 'secondkey': 'a short value', | ||
| 'thirdkey': 'a very very very' |
There was a problem hiding this comment.
Just to share what other IDE is already doing with respect to this issue.
PyCharm will automatically do this for you
'thirdkey':
'a very very very'
'long value that continues on the next line'
'and even on the line after that.',
And this too
'thirdkey': 'a very very very'
'long value that continues on the next line'
'and even on the line after that.',
But it will not do this one, which is being considered as a 'yes' in this proposal.
'thirdkey': 'a very very very'
'long value that continues on the next line'
'and even on the line after that.',
Perhaps something to take into account when making decision about this.
Thanks :)
There was a problem hiding this comment.
I like the option is not done by pycharm the least as well, but I didn't want to make the change to opinionated.
| @@ -121,6 +121,51 @@ Optional:: | |||
| var_one, var_two, | |||
| var_three, var_four) | |||
|
|
|||
| For dictionaries there is an extra rule. When placing a dictionary key on a new | |||
There was a problem hiding this comment.
nitpicky 😅 there should be a comma
For dictionaries, there is ...
... on a new line, an additional ...
|
@warsaw, I don't think it occurs very often and so I understand your point. The places where I found it was when writing an JSON response in dict form and having the error message passing the 80 character limit. This can even happen for relatively short strings when the code is nested a lot. However, currently when reading PEP8 it does not even "allow" other behaviour (I know it's just a guideline), which I think would at least be a good addition. |
|
On Oct 09, 2016, at 08:47 AM, Jelte Fennema wrote:
Re-read the "A Foolish Consistency..." section. :) Ultimately, you do what you have to to make the code as readable as possible. |
Agreed. But then it's also a matter of tools like pycodestyle accepting it (and not having to add a |
|
Quite possibly the tools should not enforce just a single style for this
case. I am happy to leave PEP 8 (the style guide) out of this debate, and
implicitly allow either form, so programmers can choose how to do this. If
the tools make their users unhappy that's between the users and the tools.
|
|
👍 |
|
Looks like after all we don't want PEP 8 to require a particular style for this specific case. It's pretty obscure anyway. If you don't like that error in your flake8 output just configure the tool to ignore this error. It's not a mortal sin. :-) |
This adds a new indenting rule to PEP8 to make it easy to differentiate between
keys and values of dictionaries. This was already shortly discussed in the
python-ideas mailinglist:
https://mail.python.org/pipermail/python-ideas/2016-October/042753.html