Re: Proposal: format GDB Python files with black

[Simon Marchi <simon.marchi@polymtl.ca>]

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.

Simon