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
>
> wrote:
>
> >
> >
> > On Mon, Nov 15, 2021 at 3:02 PM Sebastian Berg
> >
> > 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
> > > >
> > > > wrote:
> > > > >
> > >
> > >
> > >
> > > > >
> > > 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: chris.bar...@noaa.gov
> >
>
>
> ___
> 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: sebast...@sipsolutions.net
signature.asc
Description: This is a digitally signed message part
___
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
