On Thu, 2021-11-18 at 09:41 -0800, Chris Barker wrote:
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.
Personally, I would be OK with the "all in one go". At the very least it will help us get used to whatever style we got faster. Git can even mark commits as "only style fixups" I think to hide them from `git blame` and following history has never bothered me too much; the only thing that seems tricky there is when functionality is moved between files. The main downside to me is probably that it will creating conflicts in all open PRs. With some coordination/announcement that is maybe OK. Cheers, Sebastian
-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
_______________________________________________ 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: sebastian@sipsolutions.net