From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vM+fFRH8hmDTagAAWB0awg (envelope-from ) for ; Mon, 26 Apr 2021 13:44:49 -0400 Received: by simark.ca (Postfix, from userid 112) id 4C95F1F11C; Mon, 26 Apr 2021 13:44:49 -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 9C2EB1E54D for ; Mon, 26 Apr 2021 13:44:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 540483892024; Mon, 26 Apr 2021 17:44:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 540483892024 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1619459088; bh=T4l9C/dybfXH8wHaZZatMdvn/QjNTczfoPPxGJ/+rLw=; 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=c5dWrUzZPylkV9jPxdg1BiX32KrI3a9Fts8ZxLHfeI4ryiX0DRBYjxdv2X5al3icb LA0FVJK/dIknIg37kv3GEThFYjoeMCQOc1pLt7XgjG3pK4K4DTXCzO55XPMKUVxxcc Y5wBkNh1aiApCoZeAh9rS6mHIoYQx7R10az9s2jQ= 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 References: 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-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: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