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 great deal of our code is Cython
On Thu, Apr 2, 2020 at 9:00 AM Jacek Pliszka <jacek.plis...@gmail.com> wrote: > > 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 <anto...@python.org> napisał(a): > > > > > > 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") > > > > Regards > > > > Antoine. > > > > Le 02/04/2020 à 15:30, Antoine Pitrou a écrit : > > > > > > 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 insertions(+), 118 deletions(-) > > > > > > I've configured black to try and minimize changes (for example, avoid > > > normalizing string quoting style). Still, the number of changes is > > > humongous and they add 2600 lines to the codebase (which is a tangible > > > amount of vertical space). > > > > > > Regards > > > > > > Antoine. > > >
