On Mon, Nov 15, 2021 at 3:02 PM Sebastian Berg <sebast...@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 > > <j...@fastmail.com> > > wrote: > > > > > <snip> > > > > > https://github.com/jni/skan/blob/74507344b4cd4453cc43b4dbd0b5742fc08eb5a0/.style.yapf > > > > > > 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-le...@python.org https://mail.python.org/mailman3/lists/numpy-discussion.python.org/ Member address: arch...@mail-archive.com
