On Fri, May 6, 2022 at 2:10 AM Sebastian Berg <sebast...@sipsolutions.net> wrote:
> On Thu, 2022-05-05 at 15:32 -0700, Stefan van der Walt wrote: > > On Thu, May 5, 2022, at 12:00, Trevor Gross wrote: > > > I don't necessarily know that this should be enforced on CI off the > > > bat (though in the future it could be), but at least having the > > > tool available and easily usable would help to incrementally > > > improve codebase style, and remove the need for formatting by hand. > > > > On all projects we've set up pre-commit with style formatting, it has > > significantly reduced noise and nitpicks in PR discussions. It makes > > for a better contributor experience, thus I am in favor. Black isn't > > perfect by any means, but never having to talk about formatting again > > makes it worth it! > > > While I have no love for blacks style (yet), it seems time to seriously > consider adopting it. > There was the `yapf` idea (more forgiving/closer to what we have), but > I am unclear whether it is as easy to set up, especially since many > projects settled on black. > > For the C-code we have a clang-tidy setup which is decent and we could > use, I am not sure what the PR currently does? > > > In general, I still like to defer to Chuck to make the decisions in the > hope that makes it simpler to reach a verdict, here :). > Heh. I think automatic formatting is the future and was happy to see the PR. The only question is if black is the way we want to go. IIRC, the main sticking points were - Line length (<= 79). - Quotation mark changes (noisy). - Formatting of '*', '**', and '/' Even if the result isn't perfect by our current standards, I suspect we will get used to it and just not worry anymore. The main problem I've run into before is the formatting of large test data sets, which are often easier to read if the format is not strictly conforming. But that isn't something we are likely to see every day anyway. The main things we should shoot for are consistency, readability, and ease of use. The choice of a particular style is secondary. > > When it comes to reformatting the code base: I think we should maybe > just do it. Is a semi-black code base really better than just getting > it over with and needing a bit to get used to it? [1] > Cheers, > > Sebastian > > > [1] The main thing that it might disrupt are backports? In which case > I guess very late in the dev-cycle would be the right time, to avoid > cross style-change backports as much as possible. > That happened with the rearrangement of the Fortran files, I wasn't able to backport some fixes. But that was a much bigger change than the style changes proposed here. Chuck
_______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
