hakancelikdev/unimport

Spurious blank line added after last item in `from` import lists whenever files are modified

CAM-Gerlach opened this issue · 5 comments

Whenever Unimport modifies a file using --remove, it adds spurious blank lines after the last item in a list of from imports and before the parenthesis, even if the actual import modified was nowhere near there. There doesn't appear to be an obvious reason for this and it conflicts with every style guide I know of, particularly black which uses this style for from imports.

I'm not sure if this is a bug in LibCST like #100 or something that can be fixed on unimport's end, but without other tools in the pipeline to fix this (e.g. ensuring blacken is run after unimport, e.g. with pre-commit), this means that --remove is injecting style violations into any file it modifies (presuming it contains imports of this style, as anything making significant use of typing likely does), so a fix would be much appreciated.

Let me know if I can help test further or you need more information from me. I've tested this under Python 3.9 using a fresh install of unimport 0.8.4 in an isolated env (via pre-commit) with the latest deps as of today. Thanks!

Minimal example that repros:

import sys
from typing import (
    List,
)

test_list: List[str] = ["spam", "eggs"]

Expected:

from typing import (
    List,
)

test_list: List[str] = ["spam", "eggs"]

Actual:

from typing import (
    List,

)

test_list: List[str] = ["spam", "eggs"]

Thank you for reporting the issue.

Thanks @hakancelik96 !

@hakancelik96 FYI, the changelog entries for this change are not rendering correctly in your docs. Evidently, unlike the GitHub GFM parser, the Mkdocs Markdown parser seems it does not support the nested bullets you are using nor code blocks within bullets, which makes your entries that look fine on GitHub (where they aren't readily discoverable, due to your changelog's non-standard location and file name) but render borked on your docs site. Judging by other entries (e.g. 0.2.6.1), omitting the nested bullets and just putting your fenced code inline in the top-level bullet block seems to work, so I suggest something like that to fix it.

@CAM-Gerlach Thanks for letting me know, I fixed the problem.

Thanks! I can confirm it is indeed fixed.