Formatter: Preserve leading empty lines of indented classes and functions

[konstin]

While the behavior for empty lines before top level classes and functions looks correct, indented classes and function can gain or lose their leading newlines

black:

def f():
    ...
    # comment

    class Meta:
        pass

    if True:

        def register_type():
            pass

ours:

def f():
    ...

    # comment

    class Meta:
        pass

    if True:
        def register_type():
            pass

[charliermarsh]

I'm working on this.

[charliermarsh]

I've noticed a few other incompatibilities after looking back at my old implementation:

1. The first entry does need a separator if it's a class or function within a nested
   body that isn't a class or function. Also, Black allows one blank line between a
   class and its docstring (the same does not apply to functions).
2. If a function or class has a leading comment, then a blank line, we don't want to
   add one before the comment. The enforcement around
   is_last_function_or_class_definition || is_current_function_or_class_definition
   should be relative to the function or class definition, not its leading comments.
3. We're not inserting newlines after imports.
4. Black requires one newline after a class docstring.

(2) will cause problems with the current approach, I think. As an example, given:

x = 1
# comment

def f():
    pass

Black wants:

x = 1
# comment


def f():
    pass

Whereas we do:

x = 1


# comment

def f():
    pass

That means the code that handles newlines-after-comments needs to now be aware of the thing it's commenting, the level of nesting, etc.

[charliermarsh]

Perhaps the "easiest" way to get this to work would be to make # comment a trailing comment on the previous node, not a leading comment on the function, if there's at least one blank line between the comment and the function?

[charliermarsh]

(I will own all of those deviations.)

[MichaReiser]

(I will own all of those deviations.)

Are you looking for input or are these comment's meant as documentation?

[charliermarsh]

The deviations are just meant as documentation, not expecting any input! Unless you have a quick reaction to the idea I suggested in ‘Perhaps the "easiest" way to get this to work…’, but I haven’t spent time validating that yet.

[MichaReiser]

Perhaps the "easiest" way to get this to work would be to make # comment a trailing comment on the previous node, not a leading comment on the function, if there's at least one blank line between the comment and the function?

I think that could work well. Not sure if implementing custom placement is necessarily easy.