Re: Run formatting tools

[Jonas Hahnfeld]

Am Freitag, den 25.09.2020, 14:13 +0200 schrieb Jean Abou Samra:
> Le 25/09/2020 à 12:58, Han-Wen Nienhuys a écrit :
> > On Fri, Sep 25, 2020 at 9:36 AM Jonas Hahnfeld <hahnjo@hahnjo.de> wrote:
> > > Am Freitag, den 25.09.2020, 09:31 +0200 schrieb Werner LEMBERG:
> > > > > What puzzles me a bit is the magnitude of changes from autopep8 - I
> > > > > thought this tool was run in August? Maybe I'm missing something;
> > > > > FWIW I used the invocation "autopep8 -ia --ignore=E402" as
> > > > > documented in CG.
> > > > > 
> > > > > Thoughts, objections? Should I exclude running autopep8?
> > > > 
> > > > I was told from a Python professional developer that the best tool for
> > > > formatting python code be `black`.  Running
> > > > 
> > > >   black -l 78 ...
> > > > 
> > > > gives indeed very nice formatting (not tested with lilypond stuff,
> > > > though).
> > > 
> > > Hm, I thought we agreed on using autopep8 more than two months ago? I'm
> > > not very familiar with either tool but I'm against switching back and
> > > forth multiple times, that'll just cause churn in the code.
> > > 
> > 
> > IIRC I think the option used was -aa (2x -a = aggressive.)
> 
> It's the opposite, actually. I ran autopep8 wit the default level of
> aggressivity (no -a option), to be sure not to cause any regressions. Since
> then the right fixes to exclude were found and we put something different
> into the CG.
> 
> Black may be a good option. A good reason for using autopep8 back in the
> time was its fix for invalid escape sequences. Which turned out to be
> catastrophic. Since they are all fixed by now, and the interpreter will
> emit warnings during bytecode compilation if any new are added, I don't
> see any reason not to switch to Black. It's much less configurable, with
> just good defaults, and has become a standard tool nowadays as far as I
> can see (at least, it's in the PSF organisation on GitHub).
> 
> You could put this in a pyproject.toml file:
> 
> [tool.black]
> line-length=78
>
> Then the command would be just ``black .``

Not sure why 78 characters? PEP 8 says 79 characters for code or at
most 72 for doc-strings.

Anyway, running black on all Python files gives the following error:

    error: cannot format 
/code/LilyPond/src/scripts/auxiliar/translations-status.py: INTERNAL ERROR: 
Black produced different code on the second pass of the formatter.

Also, it seems to change every occurrence of single quotes to double
quotes unless there are already double quotes. My impression is that
single quotes are used more widespread, and the diff is massive at
56 files changed, 10819 insertions(+), 7704 deletions(-)

I don't care enough of the Python formatting for now so I've removed
that commit from the mentioned MR. The obvious caveat is that we must
not run such large-scale formatting if we finally create a stable
branch (not discussed here), or apply the same run for the branch as
well.

Jonas

signature.asc
Description: This is a digitally signed message part