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

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 format` that 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!

[1]  Does anybody have experience in rebasing branches across a
massive reformatting by upstream?  Are there best practices here?

Mailman-Developers mailing list -- mailman-developers@python.org
To unsubscribe send an email to mailman-developers-le...@python.org
Mailman FAQ: https://wiki.list.org/x/AgA3

Security Policy: https://wiki.list.org/x/QIA9

Reply via email to