Format code using Black?

[JukkaL]

There have been suggestions to use Black to format the mypy (and mypyc) codebase for a long time. Maybe it's time to actually do the switch now?

We'd need a volunteer to drive the project. I don't expect it to be a lot of work, but we'd need to at least update contributor documentation and pip dependencies. We'd also need to decide whether we'd fail a PR if it's not correctly formatted.

Next steps:

• Find a volunteer who'd like to drive this
• Collect feedback from contributors
• Write a more detailed plan about what needs to be done (if most contributors are happy with this or at least don't hate the idea)
• Merge some PRs as many of them will get merge conflicts after the switch? Or leave comments asking the contributors to run black themselves?
• Implement the switch

[hauntsaninja]

Seems fine to me, although I'd like us to merge PRs before doing this (I recently got a number of PRs merge-conflict free, but haven't had time / knowledge to review them). I'd also prefer it if mypy kept its current line length.

[97littleleaf11]

Personally speaking, I'm quite like the black coding style. Also, I agree that we might still keep the line length to 99.

[97littleleaf11]

Several things need to discuss which would bring lots of style change to current codebase:

• Black uses double quotes " while mypy uses single quote ' primally
• Black splits () and let each item take one line. (imports, function calls, logical expressions, etc)

[JukkaL]

@97littleleaf11 Those style changes would be necessary, since Black doesn't have many configuration options. Since they would change a large fraction of lines, many open PRs would get merge conflicts.

I can dedicate some time to reviewing PRs before we implement the switch. It would be good to have a timeline for the switch announced at least a few weeks ahead of time, so that there's time to merge a bunch of open PRs.

[JelleZijlstra]

We now have a PR open for applying Black: #12424 (thanks @KotlinIsland!). As you might imagine, I'm also in support of adopting Black if there's consensus among the other maintainers.

A useful tool to add would be pre-commit.ci, which provides a GH Action that can run on PRs and automatically format them. This has been very helpful on typeshed and could ease the pain for existing PRs that would otherwise get merge conflicted after we fix Black.

[jhance]

I think we don't need to be too nervous about existing PRs. Its pretty easy to automatically rebase such PRs with something like:

1. First rebase to the commit prior to black
2. Run black on the top of your PR.
3. Re-parent your diff on top of the black commit (NOT a rebase). You can do this by checking out the black commit and then doign git checkout your-pr . for example.

Not sure if what the github action does is quite as good as this, it could be an option too for existing PRs.

[KotlinIsland]

Thanks @jhance, I think it's important to communicate these steps onto all conflicting PR's, I will add it to the OP in the Black PR.

[KotlinIsland]

@JukkaL The PR is fully formed I think, what steps should we take next?

[q0w]

Maybe it's worth adding pycln as it was done in python/typeshed#8304?

[KotlinIsland]

@q0w That seems more like a linter, and less like a formatter. I don't want to bloat this change because it's already hard enough.

[KotlinIsland]

I found a really good strategy to rebase conflicting PR branches:

1. Rebase onto the configuration commit (not the format commit).
2. Interactively rebase from the start of your branch pausing on every commit.
3. Run git checkout --theirs .; black .; isort .; git add -A; git rebase --continue (set GIT_EDITOR=true to skip the message dialogue)
4. repeat 3 until you pass over all commits
5. Once complete rebase onto master