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

Black does not create pylint-compatible code #1127

Closed
Martmists-GH opened this issue Oct 31, 2019 · 7 comments
Closed

Black does not create pylint-compatible code #1127

Martmists-GH opened this issue Oct 31, 2019 · 7 comments
Labels
T: style What do we want Blackened code to look like?

Comments

@Martmists-GH
Copy link

Martmists-GH commented Oct 31, 2019

Pylint error code: C0330 (bad-continuation; i.e. "Wrong hanging indentation before block")

Original code snippet

class CheckHandler(object):
    def __init__(self, file, out_json, check_dir=u".", files=None):  # type: (str, bool, str, typing.List[str]) -> None
        # Do this here so setup.py doesn't error
        from snekchek.baseconfig import config
        import configobj

Examples in the current Black style

class CheckHandler(object):
    def __init__(
        self, file, out_json, check_dir=u".", files=None
    ):  # type: (str, bool, str, typing.List[str]) -> None
        # Do this here so setup.py doesn't error
        from snekchek.baseconfig import config
        import configobj

Note how the function parameters are on the same indentation level as the function body.

Desired style

# Ideal: comment moved down to fit width
# Note that getting this to work while preserving pylint/flake8 markers is quite the challenge
class CheckHandler(object):
    def __init__(self, file, out_json, check_dir=u".", files=None):  
        # type: (str, bool, str, typing.List[str]) -> None
        # Do this here so setup.py doesn't error
        from snekchek.baseconfig import config
        import configobj

# Alternatively, indent as recommended by pylint
class CheckHandler(object):
    def __init__(
            self, file, out_json, check_dir=u".", files=None
    ):  # type: (str, bool, str, typing.List[str]) -> None
        # Do this here so setup.py doesn't error
        from snekchek.baseconfig import config
        import configobj

It does this in various situations, but the core of the issue stays the same; The newer line ends up on the same indentation level as the function body

@Martmists-GH Martmists-GH added the T: style What do we want Blackened code to look like? label Oct 31, 2019
@JelleZijlstra
Copy link
Collaborator

Black is unlikely to change such a core aspect of its formatting style at this stage. I recommend that you turn off any formatting-related errors from linters if you run Black on your codebase.

@Martmists-GH
Copy link
Author

Is it possible to add a flag in the config to disable/change this behavior?

@zsol
Copy link
Collaborator

zsol commented Oct 31, 2019

Sorry, no. As explained in the README, Black is striving for a single codestyle with minimal configuration.

@claird-ot
Copy link

If I understand correctly, Black has chosen to diverge from PEP8 on this point, because the latter emphasizes "... an extra level of indentation ..." for function arguments.

While I naively prefer Black's choice to that in PEP8, I ask confirmation from those who've studied this more: do Black and PEP8 make different choices for indentation of function arguments?

@vianney-g
Copy link

vianney-g commented Nov 22, 2019

This breaks the Black's contract:

The coding style used by Black can be viewed as a strict subset of PEP 8.
README.md

@claird-ot
Copy link

claird-ot commented Nov 22, 2019

I want to be sure I understand.

For our convenience, I identify

def f1_(
    arg1, ...
# four-space indent

as Style A and

def f1_(
        arg1, ...
# eight-space indent

as style B.

When vianney-g writes, "This breaks the Black's contract", I think vianney-g is saying that:

  • Black enforces Style A;
  • PEP8 prescribes Style B;
  • Style A and Style B are not consistent, and, in particular, Style A canNOT be viewed "... as a strict subset ..." of Style B; and therefore
  • Black appears not to uphold its contract in this one regard.

I welcome any correction in my understanding.

@vidstige
Copy link

😢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: style What do we want Blackened code to look like?
Projects
None yet
Development

No branches or pull requests

6 participants