Re: [Python] black vs. autopep8

2020-04-10 Thread Micah Kornfield
My preference order would be: "black" then "autopep8" then "no change" Echoing Joris's and Neal's comments I'm a huge fan of having tools fix things for me (and the more it handles the better). Maybe I just need to setup my editor better to deal with PEP8 issue but I find I spend more time then

Re: [Python] black vs. autopep8

2020-04-09 Thread Joris Van den Bossche
> > So autopep8 doesn't fix everything? Sounds inferior to me. That said, I'm > > in favor of any resolution that increases our automation of this and > > decreases the energy we expend debating it. > > It does fix everything, where "everything" is compliance with PEP8, > which I think is the thing

Re: [Python] black vs. autopep8

2020-04-09 Thread Rok Mihevc
+1 for autopep8 On Thu, Apr 9, 2020 at 4:45 PM Wes McKinney wrote: > So to summarize, it seems that what we are agreeing in this thread is > to not debate readability about otherwise PEP8-compliant Python code > in code reviews, is that right? Absent a consensus about a change, the > outcome is

Re: [Python] black vs. autopep8

2020-04-09 Thread Wes McKinney
So to summarize, it seems that what we are agreeing in this thread is to not debate readability about otherwise PEP8-compliant Python code in code reviews, is that right? Absent a consensus about a change, the outcome is basically "no change". The addition of autopep8 as a tool for automated PEP8 f

Re: [Python] black vs. autopep8

2020-04-09 Thread Uwe L. Korn
The non-configurability of black is one of the strongest arguments I see for black. The codestyle will always be subjective. From previous discussions I know that my personal preference of readability conflicts with that of Antoine and Wes, so will probably others. We have the same issue with us

Re: [Python] black vs. autopep8

2020-04-08 Thread Xinbin Huang
Another option that we can look into is yapf ( https://github.com/google/yapf). It is similar to black but more tweakable. Also, it is recently adopted by the Apache Beam project. PR is here https://github.com/apache/beam/pull/10684/files Bin On Wed, Apr 8, 2020 at 1:18 PM Wes McKinney wrote: >

Re: [Python] black vs. autopep8

2020-04-08 Thread Wes McKinney
I don't think it's possible unfortunately. From the README: "Black reformats entire files in place. It is not configurable." The main concern about Black is the impact that it has on readability. I share this concern as the subjective style choices it makes are quite different from the way I've be

Re: [Python] black vs. autopep8

2020-04-08 Thread Rok Mihevc
Could we 'tone down' black to get the desired behavior? I'm ok with either tool. Rok On Wed, Apr 8, 2020 at 8:00 PM Wes McKinney wrote: > On Wed, Apr 8, 2020 at 12:47 PM Neal Richardson > wrote: > > > > So autopep8 doesn't fix everything? Sounds inferior to me. That said, I'm > > in favor of a

Re: [Python] black vs. autopep8

2020-04-08 Thread Wes McKinney
On Wed, Apr 8, 2020 at 12:47 PM Neal Richardson wrote: > > So autopep8 doesn't fix everything? Sounds inferior to me. That said, I'm > in favor of any resolution that increases our automation of this and > decreases the energy we expend debating it. It does fix everything, where "everything" is c

Re: [Python] black vs. autopep8

2020-04-08 Thread Neal Richardson
So autopep8 doesn't fix everything? Sounds inferior to me. That said, I'm in favor of any resolution that increases our automation of this and decreases the energy we expend debating it. Neal On Wed, Apr 8, 2020 at 10:34 AM Wes McKinney wrote: > Circling back on this, it seems there isn't cons

Re: [Python] black vs. autopep8

2020-04-08 Thread Wes McKinney
Circling back on this, it seems there isn't consensus about switching to Black, and using autopep8 at least will give us an easy way to maintain PEP8 compliance and help contributors fix linting failures detected by flake8 (but not all, e.g. unused imports would need to be manually removed). Would

Re: [Python] black vs. autopep8

2020-04-02 Thread Wes McKinney
I'm personally fine with the Black changes. After the one-time cost of reformatting the codebase, it will take any personal preferences out of code formatting (I admit that I have several myself, but I don't mind the normalization provided by Black). I hope that Cython support comes soon since a gr

Re: [Python] black vs. autopep8

2020-04-02 Thread Jacek Pliszka
Hi! I believe amount of changes is not that important. In my opinion, what matters is which format will allow reviewers to be more efficient. The committer can always reformat as they like. It is harder for the reviewer. BR, Jacek czw., 2 kwi 2020 o 15:32 Antoine Pitrou napisaƂ(a): > > > PS:

Re: [Python] black vs. autopep8

2020-04-02 Thread Antoine Pitrou
PS: in both cases, Cython files are not processed. autopep8 is actually able to process them, but the comparison wouldn't be apples-to-apples. (that said, autopep8 gives suboptimal results on Cython files, for example it changes "&c_variable" to "& c_variable" and "void* ptr" to "void * ptr")

[Python] black vs. autopep8

2020-04-02 Thread Antoine Pitrou
Hello, I've put up two PRs to compare the effect of running black vs. autopep8 on the Python codebase. * black: https://github.com/apache/arrow/pull/6810 65 files changed, 7855 insertions(+), 5215 deletions(-) * autopep8: https://github.com/apache/arrow/pull/6811 20 files changed, 137 insert