Re: Proposal: format GDB Python files with black

[Lancelot SIX via Gdb-patches <gdb-patches@sourceware.org>]

Hi

I have been using black on a few project and it is overall an enjoyable
experience.  It is also quite nice to have for new contributors with
limited experience with a particular coding style in place.  It gets
this out of the way.

As this has been mentioned earlier in the discussion[1], black output
might change slightly between versions.  I sometimes had some continuous
integration build fail because the version on the development
environment and the one running `black --check` differ.  The differences
are minor but this is  worth keeping in mind if “false positive” are an
issue, for example if it rejects commits in server-side scripts as
mentioned in [2].  That being said, specifying which version to use
solves the problem easily.  Another option can be to use 'black' to
help format the code and 'pycodestyle'[3] to do the automated checks,
but I am not sure this is the way you want to go to, introducing more
and more tools.

I’d also like to point out that by default, 'black' will use 88 char
long lines[4], which is not compliant with the PEP8[5], which is, as you
pointed out[1], referenced in GDB's wiki[6].  Either the tool's
configuration or the standard can be adjusted, depending on the
maintainers preferences.

For what it is worth, I really think black is a great tool that can
simplify development workflow.

Lancelot.

[1] https://sourceware.org/pipermail/gdb-patches/2021-April/178209.html
[2] https://sourceware.org/pipermail/gdb-patches/2021-April/178200.html
[3] https://pypi.org/project/pycodestyle/
[4] https://black.readthedocs.io/en/stable/the_black_code_style.html#line-length
[5] https://www.python.org/dev/peps/pep-0008/#maximum-line-length
[6] https://sourceware.org/gdb/wiki/Internals%20GDB-Python-Coding-Standards