From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 3GRsJvT8hmDyagAAWB0awg (envelope-from ) for ; Mon, 26 Apr 2021 13:48:36 -0400 Received: by simark.ca (Postfix, from userid 112) id 8D3981F11C; Mon, 26 Apr 2021 13:48:36 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C1CEA1E54D for ; Mon, 26 Apr 2021 13:48:35 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 58A3A3892451; Mon, 26 Apr 2021 17:48:35 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 58A3A3892451 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619459315; bh=iI1CZc8wY7abHMm6Mo1jzsFDRUzRpE2vl0NsGolWbTo=; h=Subject:To:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZD+HUFS1AjbZj6a7pIKEyUmNTeHCaxbfw8bkzqcM4jo/5/vEWKIzXky6M/ANGRu5u 9PuFmoHvUAYBXVullQw+MubYfpDD4J64VGc9m80PFkDz/Q/AZqmCtCYsT/w/sLciPc /sUh++Mc4OZZwV965LRprhAK4Vh00wRZqnAwSfLs= Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id D12CE394FC00 for ; Mon, 26 Apr 2021 17:48:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D12CE394FC00 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 13QHmK2w027062 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 26 Apr 2021 13:48:25 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 13QHmK2w027062 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 8AE031E54D; Mon, 26 Apr 2021 13:48:20 -0400 (EDT) Subject: Re: Proposal: format GDB Python files with black To: Paul Koning References: <950d8490-da1e-b6f4-fb87-c58548bb57f6@polymtl.ca> Message-ID: Date: Mon, 26 Apr 2021 13:48:20 -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: <950d8490-da1e-b6f4-fb87-c58548bb57f6@polymtl.ca> 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:48:20 +0000 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: , From: Simon Marchi via Gdb-patches Reply-To: Simon Marchi Cc: "gdb-patches@sourceware.org" Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" 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 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