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

Remove empty lines between a function's doc string and body #2189

Closed
ggoodvin-fincad opened this issue May 4, 2021 · 3 comments
Closed

Remove empty lines between a function's doc string and body #2189

ggoodvin-fincad opened this issue May 4, 2021 · 3 comments
Labels
F: empty lines Wasting vertical space efficiently. R: duplicate This issue or pull request already exists T: style What do we want Blackened code to look like?

Comments

@ggoodvin-fincad
Copy link

ggoodvin-fincad commented May 4, 2021

Black v21.4b2

Playground link

Options

--line-length=88
--safe

Input

def some_func():
    """Doc string."""
    
    return 1.0
    
def some_other_func():
    """Doc string."""
    return 2.0

Output

def some_func():
    """Doc string."""

    return 1.0


def some_other_func():
    """Doc string."""
    return 2.0

Expected

def some_func():
    """Doc string."""
    return 1.0


def some_other_func():
    """Doc string."""
    return 2.0

(Or insert a single empty line in both cases, no strong preference, just after consistency).

@felix-hilden
Copy link
Collaborator

If I had to choose, it would be removed. Multi-line docstrings in particular have a good visual distinction with the first line already:

def foo():
    """
    Docstring.

    On multiple lines explaining the function
    that needs documentation.
    """
    return 1 + 1 == 2

But I don't feel strongly about one-line docs. Looking at my own code I tend to write without the empty line, but I can imagine others might want it for separation. What do the maintainers think?

@ichard26 ichard26 added F: empty lines Wasting vertical space efficiently. T: style What do we want Blackened code to look like? labels May 4, 2021
@xrisk
Copy link
Contributor

xrisk commented May 5, 2021

Perhaps look at what some of the repos that primer checks does (or other authoritative sources)? There should be some strong precedent for enforcing one style over another I think.

@felix-hilden
Copy link
Collaborator

Looks like this is essentially the same as #2370, and since there's been more discussion over there I'll close this one as a duplicate.

@felix-hilden felix-hilden added the R: duplicate This issue or pull request already exists label Mar 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: empty lines Wasting vertical space efficiently. R: duplicate This issue or pull request already exists T: style What do we want Blackened code to look like?
Projects
None yet
Development

No branches or pull requests

4 participants