Re: Proposal to use Black for automatic formatting of Python code

[Antoine Pitrou <so...@pitrou.net>]

I have looked at the kind of reformatting used by black and I've become
-1 on this.  `black` is much too aggressive and actually makes the code
less readable.

`autopep8` seems much better and less aggressive. Let's use that
instead.

Regards

Antoine.


On Thu, 26 Mar 2020 20:37:01 +0100
Joris Van den Bossche <jo...@gmail.com> wrote:
> Hi all,
> 
> I would like to propose adopting Black as code formatter within the python
> project. There is an older JIRA issue about this (
> https://issues.apache.org/jira/browse/ARROW-5176), but bringing it to the
> mailing list for wider attention.
> 
> Black (https://github.com/ambv/black) is a tool for automatically
> formatting python code in ways which flake8 and our other linters approve
> of (and fill a similar role to clang-format for C++ and cmake-format for
> cmake). It can also be added to the linting checks on CI and to the
> pre-commit hooks like we now run flake8.
> Using it ensures python code will be formatted consistently, and more
> importantly automates this formatting, letting you focus on more important
> matters.
> 
> Black makes some specific formatting choices, and not everybody (me
> included) will always like those choices (that's how it goes with something
> subjective like formatting). But my experience with using it in some other
> big python projects (pandas, dask) has been very positive. You very quickly
> get used to how it looks, while it is much nicer to not have to worry about
> formatting anymore.
> 
> Best,
> Joris
> 

Re: Proposal to use Black for automatic formatting of Python code

[Wes McKinney <we...@gmail.com>]

On Thu, Apr 2, 2020 at 2:19 PM Antoine Pitrou <an...@python.org> wrote:
>
>
> Le 02/04/2020 à 20:58, Joris Van den Bossche a écrit :
> >
> > Yes, both autopep8 and black can fix up linting issues to ensure your code
> > passes the PEP8 checks (although autopep8 can not fix all issues
> > automatically).
> > But with autopep8 you *still* need to think about how to format your code,
> > as there
> > are many different ways you can write code that all satisfy PEP8 / autopep8.
>
> I don't understand why you need to think.
> With black: write your code as it comes and reformat it afterwards.
> With autopep8: write your code as it comes and reformat it afterwards.

With either solution, you don't have to "think" about PEP8 compliance
while programming, because autopep8 will handle it for you. There
might be some stylistic issues around where to put line breaks, but I
think what we are essentially agreeing to in this discussion is to not
make stylistic comments in code reviews so long as the code is
PEP8-compliant (which sounds good to me).

> So you can pretty much avoid thinking if you don't want to... (which
> IMHO is a weird thing to ask for, but hey :-))
>
> Regards
>
> Antoine.

Re: Proposal to use Black for automatic formatting of Python code

[Antoine Pitrou <an...@python.org>]

Le 02/04/2020 à 20:58, Joris Van den Bossche a écrit :
> 
> Yes, both autopep8 and black can fix up linting issues to ensure your code
> passes the PEP8 checks (although autopep8 can not fix all issues
> automatically).
> But with autopep8 you *still* need to think about how to format your code,
> as there
> are many different ways you can write code that all satisfy PEP8 / autopep8.

I don't understand why you need to think.
With black: write your code as it comes and reformat it afterwards.
With autopep8: write your code as it comes and reformat it afterwards.

So you can pretty much avoid thinking if you don't want to... (which
IMHO is a weird thing to ask for, but hey :-))

Regards

Antoine.

Re: Proposal to use Black for automatic formatting of Python code

[Joris Van den Bossche <jo...@gmail.com>]

Personally, I don't think autopep8 being less aggressive / more conservative
is that relevant. This is only for the single PR that does the reformatting
where black gives a much bigger number of changed lines. But once that
one-time cost is paid, using black will not give larger diffs or make more
invasive
changes.

Yes, both autopep8 and black can fix up linting issues to ensure your code
passes the PEP8 checks (although autopep8 can not fix all issues
automatically).
But with autopep8 you *still* need to think about how to format your code,
as there
are many different ways you can write code that all satisfy PEP8 / autopep8.
That's IMO an advantage of black over autopep8.

Joris

On Thu, 2 Apr 2020 at 17:40, Wes McKinney <we...@gmail.com> wrote:

> I admit that the status quo does not bother me that much, so
> `autopep8` as the more conservative / less aggressive option seems
> fine to me, and also makes it simple for people to fix up common
> linting issues in their PRs.
>
> On Thu, Apr 2, 2020 at 5:16 AM Antoine Pitrou <so...@pitrou.net> wrote:
> >
> >
> > I have looked at the kind of reformatting used by black and I've become
> > -1 on this.  `black` is much too aggressive and actually makes the code
> > less readable.
> >
> > `autopep8` seems much better and less aggressive. Let's use that
> > instead.
> >
> > Regards
> >
> > Antoine.
> >
> >
> > On Thu, 26 Mar 2020 20:37:01 +0100
> > Joris Van den Bossche <jo...@gmail.com> wrote:
> > > Hi all,
> > >
> > > I would like to propose adopting Black as code formatter within the
> python
> > > project. There is an older JIRA issue about this (
> > > https://issues.apache.org/jira/browse/ARROW-5176), but bringing it to
> the
> > > mailing list for wider attention.
> > >
> > > Black (https://github.com/ambv/black) is a tool for automatically
> > > formatting python code in ways which flake8 and our other linters
> approve
> > > of (and fill a similar role to clang-format for C++ and cmake-format
> for
> > > cmake). It can also be added to the linting checks on CI and to the
> > > pre-commit hooks like we now run flake8.
> > > Using it ensures python code will be formatted consistently, and more
> > > importantly automates this formatting, letting you focus on more
> important
> > > matters.
> > >
> > > Black makes some specific formatting choices, and not everybody (me
> > > included) will always like those choices (that's how it goes with
> something
> > > subjective like formatting). But my experience with using it in some
> other
> > > big python projects (pandas, dask) has been very positive. You very
> quickly
> > > get used to how it looks, while it is much nicer to not have to worry
> about
> > > formatting anymore.
> > >
> > > Best,
> > > Joris
> > >
> >
> >
> >
>

Re: Proposal to use Black for automatic formatting of Python code

[Wes McKinney <we...@gmail.com>]

I admit that the status quo does not bother me that much, so
`autopep8` as the more conservative / less aggressive option seems
fine to me, and also makes it simple for people to fix up common
linting issues in their PRs.

On Thu, Apr 2, 2020 at 5:16 AM Antoine Pitrou <so...@pitrou.net> wrote:
>
>
> I have looked at the kind of reformatting used by black and I've become
> -1 on this.  `black` is much too aggressive and actually makes the code
> less readable.
>
> `autopep8` seems much better and less aggressive. Let's use that
> instead.
>
> Regards
>
> Antoine.
>
>
> On Thu, 26 Mar 2020 20:37:01 +0100
> Joris Van den Bossche <jo...@gmail.com> wrote:
> > Hi all,
> >
> > I would like to propose adopting Black as code formatter within the python
> > project. There is an older JIRA issue about this (
> > https://issues.apache.org/jira/browse/ARROW-5176), but bringing it to the
> > mailing list for wider attention.
> >
> > Black (https://github.com/ambv/black) is a tool for automatically
> > formatting python code in ways which flake8 and our other linters approve
> > of (and fill a similar role to clang-format for C++ and cmake-format for
> > cmake). It can also be added to the linting checks on CI and to the
> > pre-commit hooks like we now run flake8.
> > Using it ensures python code will be formatted consistently, and more
> > importantly automates this formatting, letting you focus on more important
> > matters.
> >
> > Black makes some specific formatting choices, and not everybody (me
> > included) will always like those choices (that's how it goes with something
> > subjective like formatting). But my experience with using it in some other
> > big python projects (pandas, dask) has been very positive. You very quickly
> > get used to how it looks, while it is much nicer to not have to worry about
> > formatting anymore.
> >
> > Best,
> > Joris
> >
>
>
>