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

Always respect original comment/code-order #3800

Open
randolf-scholz opened this issue Jul 18, 2023 · 3 comments
Open

Always respect original comment/code-order #3800

randolf-scholz opened this issue Jul 18, 2023 · 3 comments
Labels
F: comments The syntactic kind. Not in the language grammar, always on our minds. Best bugs. T: enhancement New feature or request

Comments

@randolf-scholz
Copy link

Is your feature request related to a problem? Please describe.

It would be nice to be able to force black to never change the order of code and comments.

for example:

x = (
    codeA   # commentA
    .codeB  # commentB
    .codeC  # commentC
    .codeD  # commentD
    .codeE  # commentE
    .codeF  # commentF
)

gets formatted to

x = (
    codeA.codeB.codeC.codeD.codeE.codeF  # commentA  # commentB  # commentC  # commentD  # commentE  # commentF
)

which even results in breaking the 88 character limit.

Describe the solution you'd like

It feels weird that black would even ever mess with the original ordering of code and comments. Imo, the order should always be respected, since comments go together with code. If the AST contains <codeA><commentA><codeB>, then the output should be <formatted-codeA><formatted-commentA><formatted-codeB>.

@randolf-scholz randolf-scholz added the T: enhancement New feature or request label Jul 18, 2023
@JelleZijlstra
Copy link
Collaborator

I'm not sure we'll never want to reorder comments, but I agree in your example it's better to keep the comments as is. I would welcome a PR exploring a concrete change to make Black move comments less.

@JelleZijlstra JelleZijlstra added the F: comments The syntactic kind. Not in the language grammar, always on our minds. Best bugs. label Jul 22, 2023
@Feuermurmel
Copy link

@randolf-scholz I think your case is compounded by #510, where a chain of attribute accesses is put on the same line even if it exceeds the length limit. This does not happen if you had method calls instead:

x = (
    codeA()  # commentA
    .codeB()  # commentB
    .codeC()  # commentC
    .codeD()  # commentD
    .codeE()  # commentE
    .codeF()  # commentF
)

If the comments are short enough, they are reordered in respect to the code though:

x = codeA().codeB().codeC().codeD().codeE().codeF()  # A  # B  # C  # D  # E  # F

To me it seems the most reasonable way of handling comments inside of lines is to associate it with a node and then unconditionally break all parents of that node so the node with the commend is placed on a separate line. To illustrate; in the following example, the comment would be associated with 99:

x = foo([
    1, 2, 3,
    99,  # Special case.
    4, 5
])

And this would be formatted like this:

x = foo(
    [
        1,
        2,
        3,
        99,  # Special case.
        4,
        5,
    ]
)

AFAICT this is what currently already happens with # type: comments. So as a first draft, we could handle all comments like this instead of just # type: comments. @JelleZijlstra What do you think?

@JelleZijlstra
Copy link
Collaborator

Seems worth trying!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F: comments The syntactic kind. Not in the language grammar, always on our minds. Best bugs. T: enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants