This discussion and the linked gist may be of some help:
https://github.com/scikit-learn/scikit-learn/issues/11336
On Mon, Nov 22, 2021 at 12:02 PM Andrew Nelson wrote:
> Is there a way to figure out which files are not touched by any open PR?
> That way numpy might be able to do a lot more than
Is there a way to figure out which files are not touched by any open PR?
That way numpy might be able to do a lot more than an incremental code
alignment.
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to num
I think some of the pain points raised here regarding massive churn on
existing PRs & conflicts would be addressed by what Ralf said a few
emails ago:
> A detailed proposal with an incremental formatter may have a chance
here (xref `darker` and our `tools/linter.py`), a "let's just run black"
one
On 18/11/2021 19:07, Stefan van der Walt wrote:
if we do this, we should probably go through each of the 200+ open PRs (or, at
least, the non-conflicted ones), apply the formatter, and then squash the PR
into a single commit. We can do that by script.
We had to deal with this issue in scikit-
On Thu, Nov 18, 2021, at 09:51, Sebastian Berg wrote:
> 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
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
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
> >
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
> >
On Sun, Nov 14, 2021 at 4:28 PM Juan Nunez-Iglesias
wrote:
>
>
> On 15 Nov 2021, at 8:23 am, Stefan van der Walt
> wrote:
>
> On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote:
>
> The black formatter is much improved in its latest version and I think
> good enough to start using. The main
On Sun, Nov 14, 2021, at 15:26, Juan Nunez-Iglesias wrote:
> Oh, and yes, yapf does allow formatting only the diff. I agree that
> reformatting the entire code base is problematic.
That's a good point: it's possible to make these changes incrementally. There's
something called yapf-diff. It's in
I've also used uncrustify for c/c++. Of course this plays hell with
revision control.
On Sun, Nov 14, 2021 at 6:29 PM Juan Nunez-Iglesias wrote:
>
>
>
> On 15 Nov 2021, at 8:23 am, Stefan van der Walt wrote:
>
> On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote:
>
> The black formatter is
> On 15 Nov 2021, at 8:23 am, Stefan van der Walt wrote:
>
> On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote:
>> The black formatter is much improved in its latest version and I think good
>> enough to start using. The main drawbacks that I see are:
>> all operators, including '*' and '
On Sun, Nov 14, 2021, at 09:13, Charles R Harris wrote:
> The black formatter is much improved in its latest version and I think good
> enough to start using. The main drawbacks that I see are:
> * all operators, including '*' and '/', get spaces around them,
> * very long strings are not broke
On Sun, 14 Nov 2021 at 19:51, Jeff Reback wrote:
>
> in pandas we did a one time conversion to using black (a while ago) for
> python (and recently added a cython formatter); we do also have automatic
> c/cpp linters as well
>
> we have precommit rules to enforce this (and runs on ci)
>
> since
in pandas we did a one time conversion to using black (a while ago) for python
(and recently added a cython formatter); we do also have automatic c/cpp
linters as well
we have precommit rules to enforce this (and runs on ci)
since then we don’t have discussions about formatting anymore :)
woul
On Sun, Nov 14, 2021 at 11:40 AM Ralf Gommers
wrote:
>
>
> On Sun, Nov 14, 2021 at 6:14 PM Charles R Harris <
> charlesr.har...@gmail.com> wrote:
>
>> Hi All,
>>
>> This post is for discussing the automatic code formatters for C/C++/*.py
>> that are now available. The current options, as I see th
On Sun, Nov 14, 2021 at 6:14 PM Charles R Harris
wrote:
> Hi All,
>
> This post is for discussing the automatic code formatters for C/C++/*.py
> that are now available. The current options, as I see them, are
> clang-format (C/C++) and black (*.py, *.pyi, etc). Neither is perfect to my
> eye, but
17 matches
Mail list logo
