Re: Proposal: format GDB Python files with black

[Joel Brobecker <brobecker@adacore.com>]

> > Doing some kind of checking like this would be good as well.
> > We've used pycodestyle internally a bit, but recently (-ish) moved to
> > flake8.  I don't know why we made the switch or which static checker is
> > preferable, though.

flake8 does more, as it is a wrapper around pyflakes and pycodestyle.

> 
> I have used flake8 for a long time, I'm happy with it.  It does find
> some real bugs, like a variable being referenced without being assigned,
> things like that, so it has real value.
> 
> > Lancelot> I’d also like to point out that by default, 'black' will use 88 char
> > Lancelot> long lines[4], which is not compliant with the PEP8[5], which is, as you
> > Lancelot> pointed out[1], referenced in GDB's wiki[6].  Either the tool's
> > Lancelot> configuration or the standard can be adjusted, depending on the
> > Lancelot> maintainers preferences.
> > 
> > We only really chose PEP8 because it existed; not out of some deeper
> > liking for it or anything like that.  So personally I'm fine with just
> > switching to a tool.
> 
> Although PEP8 specifies more than just formatting, like naming
> convention and things like that.  So for the wiki, which mentions PEP8
> currently, I plan on saying something like "Use black for the
> formatting.  For the rest, follow PEP8.".
> 
> Let's just use black's default line length.  I certainly don't want to
> start a discussion on line length, and I don't see any reason to deviate
> from the default.

Agreed.

One other thing that I thought about is perhaps we can look at
writing a server-side hook that would be run at commit time which
would run those checks before accepting them. The git-hooks we are
using provide support for adding extra checks via the
"hooks.commit-extra-checker" option. I'm not 100% about how easy
or difficult it would be to write the actual script that would
reproduce the issue, though.

-- 
Joel