With the caveat that I am just an interested bystander, I would like to point back to yapf as an alternative. I agree with what has already been echoed by the majority of the community, that setting *some* auto-formatter is a huge benefit for both review and writing sanity. I very much disagree with some of the other choices that black makes, while in contrast I find that I can get yapf to write code that I find very close to what I would naturally write as an old-fashioned Python style pedant.
I might have already pointed to these lines of code <https://github.com/napari/napari/blob/bcb6523c0dbbbf685c93873980cf04989839b050/napari/layers/labels/labels.py#L646-L652> that black produced for napari that I find abhorrent: ( custom_colormap, label_color_index, ) = color_dict_to_colormap(self.color) I can confirm that this hurts readability because recently I and another experienced developer stared just a couple of lines downstream for a hot minute wondering where the hell "label_color_index" was defined. It is also more lines of code than custom_colormap, label_color_index = ( color_dict_to_colormap(self.color) ) (Personally I really like the pep8 recommendation on hanging indents, "further indentation should be used to clearly distinguish itself as a continuation line," which black ignores.) Anyway, didn't mean to start a flame war, just to express my preference for yapf and that it would therefore make me very happy to see NumPy adopt it as a counteracting force to the monopoly that black is developing. I do strongly agree that black is preferable to no formatter. In short my recommendation order would be: 1. Use yapf; 2. Use black; 3. Don't use a formatter. Juan. On Sat, 7 May 2022, at 3:20 PM, Peter Cock wrote: > On Fri, May 6, 2022 at 4:59 PM Charles R Harris <charlesr.har...@gmail.com> > wrote: >> >> 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. > > On that note, in black v22.1.0 (the first non-beta release), one of the > changes was to the ** operator to better suit mathematical conventions: > > "Remove spaces around power operators if both operands are simple" > https://github.com/psf/black/pull/2726 > > Either way I agree with you, most people seem to get used to black and stop > worrying about it. > > Peter > > _______________________________________________ > 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: j...@fastmail.com >
_______________________________________________ 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
