Abhilash Raj writes:
I am trying out some of the code formatting tools on Mailman repos to help reduce some efforts in development. The tools I am trying out is blue[1]
Please don't hurry to merge this to main/master. Remember that Python has been rejecting proposals to mass-PEP8 the stdlib for about 2 decades now.
I (speaking only for myself) have no objection going forward for new files and major refactorings. But if you do this all at once, I fear that most interesting diffs for the next year or so will be full of reformatting cruft, with a long tail of too-crufty-to-be-useful diffs on infrequently changed files for years. On the other hand, I don't find any Mailman code hard or annoying to read because of stylistic differences.
I'll take a look at the PRs but it will probably be a while (weeks) before I have a good sense for just how much disruption is involved.
and isort[2]
I'm cautiously in favor of this. Standardizing import format is a big enough improvement when reading code to justify the relatively small amount of churn.
I am also adding a new tox command
tox -e formatthat should run the appropriate commands locally for users to run.
What is the purpose of this? Anybody who runs it on a code base before the blue'd code gets merged is going to generate hard to read crufty PRs, no? I guess people with long-lasting feature branches may find it convenient in rebasing their branches (but I think that's going to be a massive PITA regardless[1]). I think the documentation should be *very* opinionated about getting input from core devs before blue'ing a file.
The choice of tool, blue
It's a good choice!
Footnotes: [1] Does anybody have experience in rebasing branches across a massive reformatting by upstream? Are there best practices here?