Re: Proposal: format GDB Python files with black

[Simon Marchi via Gdb-patches <gdb-patches@sourceware.org>]

On 2021-04-26 1:44 p.m., Simon Marchi via Gdb-patches wrote:> On 2021-04-26 1:34 p.m., Paul Koning wrote:> 
>>
>>> On Apr 26, 2021, at 11:55 AM, Simon Marchi via Gdb-patches <gdb-patches@sourceware.org> wrote:
>>>
>>> Hi all,
>>>
>>> A few people I talked to about this and I have good experience with the
>>> tool black to auto-format Python code.  It is simple to use, fast and
>>> reliable (if it detects that it changed the meaning of the program by
>>> mistake, internal-errors out).  I don't think I need to spell out the
>>> advantage of using such a tool, but just in case: it removes all the
>>> overhead of thinking about formatting when writing or reviewing code.
>>
>> In the case of Python, formatting is a core part of writing the code.  Apart from that, I don't see much need for this, what with Emacs editing mechanisms.
>>
>> I looked at the sample you mentioned.  It's reasonable enough except for the bizarre way of formatting a long parenthesized condition in an if statement (near the start of FrameDecorator.py).  So while I can't see any reason to use this, it seems ok as a tool that others might use if they like to do so.
>>
>> I would object to having this mandatory.
> 
> The thing is that it's difficult for some people to use an auto-format
> tool if not everybody use it.  You would always get some spurious
> formatting changes, so you would need to hand-edit the patch after that
> to avoid adding those.  You don't really save time.  What would save me
> (and everybody) some cycles is something we could just run mindlessly.
> 
> For clang-format, there is git-clang-format that formats just the lines
> touched by a commit, perhaps there's something similar with black.  That
> sounds like a good idea, but in my experience you just end up with a
> weird mix of styles that is even worse, and it still ends up
> reformatting more than what you really changed.

To be clear, I wouldn't really mind if some contributors didn't use it
(for the same reason that it's not the end of the world if formatting
errors are introduced).  If I detect that a file I want to modify is
not black-compliant, I'll just make a preparatory commit "Format foo.py
with black" and make my patch on top of that.  But I would appreciate if
we could do a first pass of formatting all the code, to have a good
baseline.

Simon