Operating system: Win7 x64
Python version: 3.6.0
Black version: black==18.3a3 installed from pypi into venv
Does also happen on master:
Code:
def doc_dl_job(
doc_ids,
dl_folder,
root_url=None,
api_username=None,
api_password=None,
updatedcontent_root_url=None,
):
'''Download documents by list of doc ids.'''
api = API(api_username, api_password, root_url=root_url)
Pylint complains about all lines with function arguments.
Command: black -l 100 testfile.py
This is a pylint problem. Pylint thinks that the arguments aren't separated visually from the body of the function. They are, by the line with the colon.
Thanks for your report but this isn't something we will change in Black.
@ambv
Why black turn block indentation into this form?
The result of yapf:
(no pylint warning)

The result of black:
(with pylint warning)

@yech1990 this is clearly explained in the readme:
You might have noticed that closing brackets are always dedented and that a trailing comma is always added. Such formatting produces smaller diffs; when you add or remove an element, it's always just one line. Also, having the closing bracket dedented provides a clear delimiter between two distinct sections of the code that otherwise share the same indentation level (like the arguments list and the docstring in the example above).
I'm also seeing the same pylint issue: Wrong hanging indentation before block (add 4 spaces).
Is there a way to have the indentation to be 4 spaces via passing in a flag? Thanks!
Please read the docs. There will be no flags to control formatting. This pylint warning is wrong, it should be disabled.
For the next person:
This is a known issue and was reported to pylint in 2014,
https://github.com/PyCQA/pylint/issues/289
In defense of pylint, to be honest, it's annoying that to collapse a function with Black's formatting, you have to collapse the definition AND then the function body (2 steps) ... :-(
@egabrum That's just a criticism of whatever you're using for code folding, not an inherent limitation of the formatting.
I think there is a misunderstanding in what pylint is saying here: Black does not add enough indent to comply with the indent recommendations in pep8 regarding function definitions:
# Correct:
...
# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.
def long_function_name(
var_one, var_two, var_three,
var_four):
print(var_one)
I do understand that black puts each parameter on a separate line on purpose (and I love the idea), but I think it should be adding an extra level of indent to the parameters for increased readability, like the following:
def doc_dl_job(
doc_ids,
dl_folder,
root_url=None,
api_username=None,
api_password=None,
updatedcontent_root_url=None,
):
'''Download documents by list of doc ids.'''
api = API(api_username, api_password, root_url=root_url)
As for the aforementioned bug report https://github.com/PyCQA/pylint/issues/289 in the pylint repository: That one is about indents for if-statements and there is still (even six years later) an ongoing discussion on the validity of that bug report (i.e. on how to interpret pep8 exactly). Guido seems to think that black violates pep8 in that regard, though: https://discuss.python.org/t/pep-8-clarify-if-multiline-argument-list-with-a-closing-on-a-separate-line-is-acceptable/2948/7
So I wouldn't consider this a hard bug, but a change I would love to see nonetheless, as it makes code more readable IMHO and makes black-formatted code a bit more pep8-compliant.
Small aside鈥攄isabling bad-continuation in my project sounds good鈥攂ut here鈥檚 something with the VSCode handling that actually seems broken. If I write a function like the one below and hit enter after the function declaration colon, the cursor does not auto-indent, e.g., like this (the pipe is showing the cursor position after I hit enter after the colon):
def foo(
bar: str
):
|
Version: 1.46.1
Commit: cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
Date: 2020-06-17T21:17:14.222Z
Electron: 7.3.1
Chrome: 78.0.3904.130
Node.js: 12.8.1
V8: 7.8.279.23-electron.0
OS: Darwin x64 18.7.0
@mrcoles that sounds like you should report it to VSCode (or whatever plugin you're using), not to Black.
I think the solution @soulmerge suggested is a good one. He's right about black not conforming to PEP8 in this way. I also think visually it is easier to see what is going on without the ): at the same indent level as def. Code folding is also easier with this style (just fold based on indentation).
def long_function_name(
a_really_long_variable_name_1,
a_really_long_variable_name_2,
a_really_long_variable_name_3,
a_really_long_variable_name_4,
):
pass
vs.
def long_function_name(
a_really_long_variable_name_1,
a_really_long_variable_name_2,
a_really_long_variable_name_3,
a_really_long_variable_name_4,
):
pass
I think the solution @soulmerge suggested is a good one. He's right about black not conforming to PEP8 in this way. I also think visually it is easier to see what is going on without the
):at the same indent level asdef. Code folding is also easier with this style (just fold based on indentation).
At the expense of commenting on a closed issue, I think the point of the others is that PEP8 is actually ambiguous here and does not explicitly disallow the formatting path chosen by black (just one that is quite similar). In either case one begins to argue about interpretations, which frankly is a flaw in the design of PEP8.
If you agree with solution purposed by @mrcoles of Disabling this specific Pylint validation and agrees with Black's approach of identation, it is possible to run:
pylint <path> --disable C0330
Then pylint will ignore C0330:Wrong hanging indentation before block (add 4 spaces) validation.
If you use pylint as linter in VSCode, you can add this to Pylint Args

Or, add it to your settings.json:
"python.linting.pylintArgs": [
"--disable C0330"
],
it is possible to run:
pylint <path> --disable C0330
It's possible, but there is not really a need to do so. Just update to pylint>=2.6.0, they have removed "C0330" entirely.
See https://github.com/PyCQA/pylint/issues/289 and the 2.6.0 release notes:
bad-continuation and bad-whitespace have been removed, black or another formatter can help you with this better than Pylint
http://pylint.pycqa.org/en/latest/whatsnew/changelog.html#what-s-new-in-pylint-2-6-0
Most helpful comment
For the next person:
This is a known issue and was reported to pylint in 2014,
https://github.com/PyCQA/pylint/issues/289