From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 4305D3892451 for ; Mon, 26 Apr 2021 17:44:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4305D3892451 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 13QHiZGC024077 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Apr 2021 13:44:40 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13QHiZGC024077 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id 46FDB1E54D; Mon, 26 Apr 2021 13:44:35 -0400 (EDT) Subject: Re: Proposal: format GDB Python files with black To: Paul Koning Cc: "gdb-patches@sourceware.org" References: From: Simon Marchi Message-ID: <950d8490-da1e-b6f4-fb87-c58548bb57f6@polymtl.ca> Date: Mon, 26 Apr 2021 13:44:35 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 26 Apr 2021 17:44:35 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2021 17:44:46 -0000 On 2021-04-26 1:34 p.m., Paul Koning wrote:> > >> On Apr 26, 2021, at 11:55 AM, Simon Marchi via Gdb-patches 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