From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gustaf Waldemarson Newsgroups: gmane.emacs.bugs Subject: bug#62696: python.el: Extra indentation for conditionals Date: Mon, 10 Apr 2023 13:11:32 +0200 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000009bb88505f8f9702d" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17558"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 62696@debbugs.gnu.org To: kobarity Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 10 13:12:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1plpRd-0004KJ-Tq for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 10 Apr 2023 13:12:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1plpRM-0008Lk-Ft; Mon, 10 Apr 2023 07:12:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1plpRL-0008LO-20 for bug-gnu-emacs@gnu.org; Mon, 10 Apr 2023 07:12:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1plpRK-0006zq-PR for bug-gnu-emacs@gnu.org; Mon, 10 Apr 2023 07:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1plpRK-0003ZJ-6c for bug-gnu-emacs@gnu.org; Mon, 10 Apr 2023 07:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Gustaf Waldemarson Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 10 Apr 2023 11:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62696 X-GNU-PR-Package: emacs Original-Received: via spool by 62696-submit@debbugs.gnu.org id=B62696.168112511113700 (code B ref 62696); Mon, 10 Apr 2023 11:12:02 +0000 Original-Received: (at 62696) by debbugs.gnu.org; 10 Apr 2023 11:11:51 +0000 Original-Received: from localhost ([127.0.0.1]:34414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plpR8-0003Yt-P5 for submit@debbugs.gnu.org; Mon, 10 Apr 2023 07:11:51 -0400 Original-Received: from mail-yw1-f176.google.com ([209.85.128.176]:43555) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1plpR7-0003Yh-2S for 62696@debbugs.gnu.org; Mon, 10 Apr 2023 07:11:49 -0400 Original-Received: by mail-yw1-f176.google.com with SMTP id 00721157ae682-5491fa028adso416491307b3.10 for <62696@debbugs.gnu.org>; Mon, 10 Apr 2023 04:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1681125103; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1CmBSZgyVwe72CfVFpic9ZiSFQtynMN4gqYh35CaapE=; b=MMx4xraAkuAA2S/jlkiu+5zDUtBWY1AfNPm+UM4SCYP0CwLSfpNBvXMd5O5CcQOx/3 We1LAwRhoW/ql1Eg8p0AmLgGg0nRbsBXdmNa5fx3mfHTJ4ReyTSEPMHKospj/ldACC2U ZdzIcxGnu/Z1b+EcbSDP6/6oWiRyf1r7mp9NXVljnysQ7bhIKg9fde41yVuUf8Maz9J5 M/2djchx84Lb8DDiY1ILvJf899p7sHvTJorVNKRNbCLv+klxd6w3yLyZTcnLe4W9XICR h0jbDrOyU1gWX69O1cm0yobpm5td5QGTrTe/gtlda18l/v0zEFS3q2KBD/ImQFy2bWdE FFWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1681125103; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1CmBSZgyVwe72CfVFpic9ZiSFQtynMN4gqYh35CaapE=; b=d+vwYkIJsVz2OXiOvW+m9BibbNsy6NtK34vbXAo+h3yXyFRSCZ2LtjRr6CQOWHvcZ6 N6fQQCMucaR3h0Bl/VC4nbsyfWABHtq+bSZudGnfONkZYs0wQPWQJAby8kKA0hEtn4O0 BWAKtsL1gJU0W5PtstpFD4yVR7hCr+Gcokfp85hHLJY/4byC5EY2c7GBVGGKtOptMhAF JW/ocpQ1z2S7yFQM22wCbIoXT2eOj/kpAVv6wHD8sL2HEfUy6ndVW4TMDFbWCUqeanj/ s9eyPNx/PTR3qIgCATWFNHl631ievcHTDSmIufJgeDRniwgyYSFMTw3EJtqXsos4dY0L rhfw== X-Gm-Message-State: AAQBX9ckBa0py41TipC5QDcwadNVQypTDLMyexElfVqcXl8BlUlkfsXb Ud5+TYbcAsfObAGecCqiwgcj9YDlKUhpta64vtc= X-Google-Smtp-Source: AKy350ajcd4B+z0YV/Nx8owsca8Pz3mKUyKvI8rul+HcXP5XrrRAnOvxZSX73Of2yMFBfsMzJjxtkVV2Q5ZtmcjoKMg= X-Received: by 2002:a81:c406:0:b0:54c:fd7:476e with SMTP id j6-20020a81c406000000b0054c0fd7476emr5676627ywi.3.1681125103350; Mon, 10 Apr 2023 04:11:43 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:259563 Archived-At: --0000000000009bb88505f8f9702d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello! Thanks a lot for this! I had no idea that they had changed the relevant PEPs to account for this, but as mentioned it is still a good idea to have the option to change this depending on your preference. And as far as I have been able to tell from coding with this patch for a few hours, it seems to work beautifully and I would love to see this as an official feature! Best regards, Gustaf Den s=C3=B6n 9 apr. 2023 kl 14:11 skrev kobarity : > > Gustaf Waldemarson wrote: > > One noticeable caveat is that **any** parenthesis can now be additional= ly > > indented, e.g., the follow is now also possible: > > > > this_is_a_tuple =3D (long_variable_name_here, > > also_a_long_variable_name) > > > > Although, given that this can be cycled at will by the user, I'm not > sure if it > > is a bad additional feature or not. > > > > Ideally, I suppose that `python-indent-context` could be modified to ad= d > a > > `:inside-cond-paren` symbol that signals that the parenthesis is for a > > conditional expression and thus the extra indentation should be applied= , > and not > > in any other case. That does seem a bit harder for me to fix at a > cursory glance > > however, so maybe this fix is enough? > > Hi Gustaf, > > I agree with you in that it's better to have a new indent context, and > I tried to implement it. > > At first, I thought that it would be enough to add a counterpart of > the user option `python-indent-def-block-scale' and corresponding > `:inside-paren-newline-start-from-block' context. > `python-indent-def-block-scale' can be used to customize the following > code > > #+begin_src python > if ( > "VALUE" in my_unnecessarily_long_dictionary > and some_other_long_condition_case > ): > do_something() > #+end_src > > to be indented as follows (with a TAB at "):" line): > > #+begin_src python > if ( > "VALUE" in my_unnecessarily_long_dictionary > and some_other_long_condition_case > ): > do_something() > #+end_src > > This is the style used by the popular formatter "black". > > From the name `python-indent-def-block-scale' and its docstring, it is > easy to assume that it only works for def block, but in fact it works > for every blocks. As `python-indent-def-block-scale' works only when > there is no item on the same line following the opening paren, I tried > to add a similar user option and an indent context for the opening > paren followed by some items on the same line. It could indent as > follows: > > #+begin_src python > if ("VALUE" in my_unnecessarily_long_dictionary > and some_other_long_condition_case): > do_something() > #+end_src > > However, it could not handle correctly the following example: > > #+begin_src python > elif (some_case or > another_case): > do_another() > #+end_src > > The extra indentation is not needed here. > > So I think it is best to increase the indentation only if the > calculated indentation equals to the indentation of the contents of > the block ("do_something()" in the above example). This is similar to > the way I fixed Bug#57262. > > Unlike Bug#57262, the current indentation shown below is not a > violation of the latest PEP8: > > #+begin_src python > if ("VALUE" in my_unnecessarily_long_dictionary > and some_other_long_condition_case): > do_something() > #+end_src > > Although pycodestyle reports E129 "visually indented line with same > indent as next logical line," PEP8 was changed to allow this. This is > explained in the following issue, for example: > https://github.com/PyCQA/pycodestyle/issues/474 > > So changing this indentation should be a user option. Attached is my > implementation of this. The user option > `python-indent-block-paren-deeper' is added to customize this > indentation. I would be glad if you could try it. > --0000000000009bb88505f8f9702d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello!

Thanks a lot for this= ! I had no idea that they had changed the relevant PEPs to account
for this, but as mentioned it is still a good idea to have the option to = change this depending
on your preference. And as far as I have be= en able to tell from coding with this patch for a
few hours, it s= eems to work beautifully and I would love to see this as an official featur= e!

Best regards,
Gustaf
<= br>
Den s= =C3=B6n 9 apr. 2023 kl 14:11 skrev kobarity <kobarity@gmail.com>:

Gustaf Waldemarson wrote:
> One noticeable caveat is that **any** parenthesis can now be additiona= lly
> indented, e.g., the follow is now also possible:
>
>=C2=A0 =C2=A0 =C2=A0this_is_a_tuple =3D (long_variable_name_here,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0also_a= _long_variable_name)
>
> Although, given that this can be cycled at will by the user, I'm n= ot sure if it
> is a bad additional feature or not.
>
> Ideally, I suppose that `python-indent-context` could be modified to a= dd a
> `:inside-cond-paren` symbol that signals that the parenthesis is for a=
> conditional expression and thus the extra indentation should be applie= d, and not
> in any other case. That does seem a bit harder for me to fix at a curs= ory glance
> however, so maybe this fix is enough?

Hi Gustaf,

I agree with you in that it's better to have a new indent context, and<= br> I tried to implement it.

At first, I thought that it would be enough to add a counterpart of
the user option `python-indent-def-block-scale' and corresponding
`:inside-paren-newline-start-from-block' context.
`python-indent-def-block-scale' can be used to customize the following<= br> code

#+begin_src python
if (
=C2=A0 =C2=A0 =C2=A0 =C2=A0 "VALUE" in my_unnecessarily_long_dict= ionary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and some_other_long_condition_case
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ):
=C2=A0 =C2=A0 do_something()
#+end_src

to be indented as follows (with a TAB at "):" line):

#+begin_src python
if (
=C2=A0 =C2=A0 "VALUE" in my_unnecessarily_long_dictionary
=C2=A0 =C2=A0 and some_other_long_condition_case
):
=C2=A0 =C2=A0 do_something()
#+end_src

This is the style used by the popular formatter "black".

>From the name `python-indent-def-block-scale' and its docstring, it is<= br> easy to assume that it only works for def block, but in fact it works
for every blocks.=C2=A0 As `python-indent-def-block-scale' works only w= hen
there is no item on the same line following the opening paren, I tried
to add a similar user option and an indent context for the opening
paren followed by some items on the same line.=C2=A0 It could indent as
follows:

#+begin_src python
if ("VALUE" in my_unnecessarily_long_dictionary
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and some_other_long_condition_case):
=C2=A0 =C2=A0 do_something()
#+end_src

However, it could not handle correctly the following example:

#+begin_src python
elif (some_case or
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 another_case):
=C2=A0 =C2=A0 do_another()
#+end_src

The extra indentation is not needed here.

So I think it is best to increase the indentation only if the
calculated indentation equals to the indentation of the contents of
the block ("do_something()" in the above example).=C2=A0 This is = similar to
the way I fixed Bug#57262.

Unlike Bug#57262, the current indentation shown below is not a
violation of the latest PEP8:

#+begin_src python
if ("VALUE" in my_unnecessarily_long_dictionary
=C2=A0 =C2=A0 and some_other_long_condition_case):
=C2=A0 =C2=A0 do_something()
#+end_src

Although pycodestyle reports E129 "visually indented line with same indent as next logical line," PEP8 was changed to allow this.=C2=A0 Th= is is
explained in the following issue, for example:
https://github.com/PyCQA/pycodestyle/issues/474
So changing this indentation should be a user option.=C2=A0 Attached is my<= br> implementation of this.=C2=A0 The user option
`python-indent-block-paren-deeper' is added to customize this
indentation.=C2=A0 I would be glad if you could try it.
--0000000000009bb88505f8f9702d--