This read by the Author of Black may be helpful. https://lukasz.langa.pl/36380f86-6d28-4a55-962e-91c2c959db7a/ Whether you use Black or a configured YAPF, or .... I think the discussion of "all in one go" is worth thinking about. -CHB On Mon, Nov 15, 2021 at 2:33 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Nov 15, 2021 at 3:02 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:
On Mon, 2021-11-15 at 14:28 -0700, Charles R Harris wrote:
On Sun, Nov 14, 2021 at 4:28 PM Juan Nunez-Iglesias <jni@fastmail.com> wrote:
<snip>
https://github.com/jni/skan/blob/74507344b4cd4453cc43b4dbd0b5742fc08eb5a0/.s...
As Stéfan said, fix the knobs (yours might be different), then forget about it!
Oh, and yes, yapf does allow formatting only the diff. I agree that reformatting the entire code base is problematic.
yapf does look like a better alternative than black.
I think we could give try yapf/clang-format a shot. Frankly, I would be very happy to just defer most/all of the knob setting and making the call on adoption to you Chuck :). (Unless maybe anyone aims for cross-project sharing of these already.)
Thanks :)
In the end, I expect we will all quickly get used to the vast majority of changes. And projects that adopted auto-formatters seem happy...
clang-format has a couple of knobs we could play around with, e.g.:
AlignAfterOpenBracket: DontAlign
helps with the `if` issue (but comes at additional indentation costs). And there are the penalty options, e.g.:
PenaltyBreakString: 150 # random value
which, if set, seem to allow a few characters beyond the 79 limit if it saves a line.
I was hoping someone else would tweak it as we gain experience. I don't think any of the formatting options should be blessed until we gain some experience. At some point it will become "good enough".
There are some places where, IMO, existing line breaks make more sense than automatic breaks:
if (npy_parse_arguments("astype", args, len_args, kwnames, "dtype", &PyArray_DescrConverter, &dtype, "|order", &PyArray_OrderConverter, &order, "|casting", &PyArray_CastingConverter, &casting, "|subok", &PyArray_PythonPyIntFromInt, &subok, "|copy", &PyArray_PythonPyIntFromInt, &forcecopy, NULL, NULL, NULL) < 0) {
where each parameter starts on its own line, and:
static struct PyMethodDef array_module_methods[] = { {"_get_implementing_args", (PyCFunction)array__get_implementing_args, METH_VARARGS, NULL}, {"_get_ndarray_c_version", (PyCFunction)array__get_ndarray_c_version, METH_VARARGS|METH_KEYWORDS, NULL}, ...
(Less clear, but in that case I really like the uniformity of having the name on its own line.)
But I guess we could add `\\` to force line breaks, or disable formatting for those method defs.
Chuck _______________________________________________ NumPy-Discussion mailing list -- numpy-discussion@python.org To unsubscribe send an email to numpy-discussion-leave@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: chris.barker@noaa.gov
-- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov