Allow newlines after block open (or not)

[vaughnkoch]

Hi, I'm opening this issue per a suggestion from @MichaReiser, based on this closed issue: #8893.

The formatting question is whether Ruff should automatically remove a blank line after a block definition:

def some_func():

    some_more_code()

to

def some_func():
    some_more_code()

The alternative is "allow zero or one" newlines, i.e. not to remove the newline if it exists, but also not to automatically add one. This is the approach that Black chose in their 2024 preview style. Full Black discussion here: psf/black#4043.

[cbandera]

Yes I can second this request as well. While investigating the transition to ruff, this inconsistency to black is causing many changes across our code base.

[MichaReiser]

Yes I can second this request as well. While investigating the transition to ruff, this inconsistency to black is causing many changes across our code base.

Thanks for reporting. Do you mainly mind that there are many differences or did you prefer black's formatting? Would you be able to share some examples where you preferred black's formatting over ruff's?

[cbandera]

Yes I can second this request as well. While investigating the transition to ruff, this inconsistency to black is causing many changes across our code base.

Thanks for reporting. Do you mainly mind that there are many differences or did you prefer black's formatting? Would you be able to share some examples where you preferred black's formatting over ruff's?

For me it's mainly about the diff that is created. Working in a big monorepo, it's always easier for us toolies to roll out changes if we don't need to touch the other devs code. Having read that ruff would be a "drop-in" replacement for black, my expectation was that I would see no diff at all.

Having said that and after looking at the known deviations I can't say that I don't agree with ruff's design decisions though...

[chicheng]

Hi, yes please add an option to preserve up to 1 empty line.

As empty lines used for separating/grouping lines, the first line(s) stay closer to block head but not the remaining parts feel like it's part of the block head (since empty line inside block content is inevitable), e.g.

block head
   part of block head

   block content
   block content
   block content

   block content
   block content

so I prefer to read as

block head

   block content
   block content
   block content

   block content
   block content

Personally I always insert an empty line at the beginning of the block, except 2 scenarios:

class B(A):

    def single_line(self):    # an empty line after `class B`, because single_line() is not closer to B than other methods
        return something    # Two exceptions that no empty line after `def instance_methods():`: 1. one liner, otherwises a few one lines consecutively will feel strange as there are equal space between block head and content and next block head and content

    def override_super(self):
        super().override_super()    # 2. `super()...` call (easier to tell whether non-one-liner class method called super or not? just personal preference probably)

        remaining_codes = ...

    def function(
        self, data: torch.Tensor | tuple[torch.Tensor, ...], other_argument: int
    ) -> torch.Tensor | tuple[torch.Tensor, ...]:
        something = do_something(data)    # An empty line above please, this line is part of method body, not head. borrowed from black issue comment

        return something

[alechouse97]

Any updates on this? This is one the last remaining issues for ruff to finally replace black in my workflow.

[michaelhball]

Also checking in to say the same as above, I think this is our last remaining "issue" with ruff.

[dcnadler]

Yes I can second this request as well. While investigating the transition to ruff, this inconsistency to black is causing many changes across our code base.

Agreed, this is what's blocking us from adopting Ruff. Too many diffs - not a "drop-in".

Looking forward to updates, thanks!

[thclark]

From the perspective of someone with dyslexia; this really makes code harder to read - I need whitespace around the block to help parse what's in it.

[plynch-chwy]

I was looking to make the switch to ruff and use the handful of ignored linting rules we use with pre-commit. After a couple of hours I only just found that this is an option I can't ignore or set as unfixable? It's kinda unfortunate that this issue is still open for almost a year as I was excited to switch.