bug#34268: 27.0.50; wrong indentation in python mode

bug#34268: 27.0.50; wrong indentation in python mode

[Sam Steingold]

emacs -Q
C-x b z.py RET
M-x python-mode

insert this code:

--8<---------------cut here---------------start------------->8---
def foo(x):
    return [bar(x)
            for y in zot(
                    x)]
--8<---------------cut here---------------end--------------->8---

Note that the last line has 4 extra indentation characters.
It should be

--8<---------------cut here---------------start------------->8---
def foo(x):
    return [bar(x)
            for y in zot(
                x)]
--8<---------------cut here---------------end--------------->8---


In GNU Emacs 27.0.50 (build 2, x86_64-apple-darwin17.7.0, NS appkit-1561.60 Version 10.13.6 (Build 17G5019))
 of 2019-01-28 built on C-6111-SSTEINGO
Repository revision: 239386806ec637419786bd1ab21e002bf2d501c1
Repository branch: master
Windowing system distributor 'Apple', version 10.3.1561
System Description:  Mac OS X 10.13.6

Configured using:
 'configure --with-mailutils --with-ns
 PKG_CONFIG_PATH=/usr/local/opt/libxml2/lib/pkgconfig:/usr/local/opt/imagemagick/lib/pkgconfig:/usr/local/opt/gnutls/lib/pkgconfig'

Configured features:
IMAGEMAGICK NOTIFY KQUEUE ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS
THREADS JSON CANNOT_DUMP LCMS2 GMP

Important settings:
  value of $LANG: C
  locale-coding-system: utf-8-unix

-- 
Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1561
http://childpsy.net http://calmchildstories.com http://steingoldpsychology.com
http://islamexposedonline.com http://americancensorship.org http://memri.org
If a train station is a place where a train stops, what's a workstation?

bug#34268: 27.0.50; wrong indentation in python mode

[Bhavin Gandhi]

On 2/1/19 2:34 AM, Sam Steingold wrote:
> --8<---------------cut here---------------start------------->8---
> def foo(x):
>      return [bar(x)
>              for y in zot(
>                      x)]
> --8<---------------cut here---------------end--------------->8---
> 

Can you please point to section from PEP8 this code violates? I tried to 
find a related section but not sure which section to consider. Also 
flake8 does not give any error for both the snippets.

bug#34268: 27.0.50; wrong indentation in python mode

[Sam Steingold]

[-- Attachment #1: Type: text/plain, Size: 786 bytes --]

pylint reports
convention (C0330, bad-continuation, ) Wrong hanging indentation before
block (remove 4 spaces).


On Tue, Feb 19, 2019 at 8:14 AM Bhavin Gandhi <bhavin7392@gmail.com> wrote:

> On 2/1/19 2:34 AM, Sam Steingold wrote:
> > --8<---------------cut here---------------start------------->8---
> > def foo(x):
> >      return [bar(x)
> >              for y in zot(
> >                      x)]
> > --8<---------------cut here---------------end--------------->8---
> >
>
> Can you please point to section from PEP8 this code violates? I tried to
> find a related section but not sure which section to consider. Also
> flake8 does not give any error for both the snippets.
>


-- 
Sam Steingold <http://sds.podval.org> <http://www.childpsy.net> <
http://steingoldpsychology.com>

[-- Attachment #2: Type: text/html, Size: 1967 bytes --]

bug#34268: Configuration option to fix the issue

[Valentin Ignatev]

[-- Attachment #1: Type: text/plain, Size: 370 bytes --]

Hey Sam, I've looked in the python.el code and it seems that it reuses
python-indent-def-block-scale for calculating an indentation.

The default value is 2 which is why inside-parens indent doubles. Setting
its value to 1 fixes the issue.

I also wonder why authors choose double indent for aligning function
arguments. Is this some kind of an oldschool code style? :)

[-- Attachment #2: Type: text/html, Size: 464 bytes --]

bug#34268: 27.0.50; wrong indentation in python mode

[Lars Ingebrigtsen]

Valentin Ignatev <valentignatev@gmail.com> writes:

> Hey Sam, I've looked in the python.el code and it seems that it reuses
> python-indent-def-block-scale for calculating an indentation.
>
> The default value is 2 which is why inside-parens indent doubles. Setting its
> value to 1 fixes the issue.
>
> I also wonder why authors choose double indent for aligning function
> arguments. Is this some kind of an oldschool code style? :) 

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

If I understand correctly (and I may well not -- I don't write much
python), this is just a preference issue, and setting
`python-indent-def-block-scale' to 1 fixes the issue?

If that's what's recommended by the standards, should we flip the
default to 1?

I've added Augusto to the CCs; perhaps he has an opinion here.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#34268: 27.0.50; wrong indentation in python mode

[Andreas Röhler]

On 22.09.21 23:57, Lars Ingebrigtsen wrote:
> Valentin Ignatev <valentignatev@gmail.com> writes:
>
>> Hey Sam, I've looked in the python.el code and it seems that it reuses
>> python-indent-def-block-scale for calculating an indentation.
>>
>> The default value is 2 which is why inside-parens indent doubles. Setting its
>> value to 1 fixes the issue.
>>
>> I also wonder why authors choose double indent for aligning function
>> arguments. Is this some kind of an oldschool code style? :)
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> If I understand correctly (and I may well not -- I don't write much
> python), this is just a preference issue, and setting
> `python-indent-def-block-scale' to 1 fixes the issue?
>
> If that's what's recommended by the standards, should we flip the
> default to 1?
>
> I've added Augusto to the CCs; perhaps he has an opinion here.
>

py-compute-indentation from  python-mode.el here jumps to the beginning 
of the list and calculates the indent by adding the default-indent of 
this line.

bug#34268: 27.0.50; wrong indentation in python mode

[Augusto Stoffel]

On Wed, 22 Sep 2021 at 23:57, Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Valentin Ignatev <valentignatev@gmail.com> writes:
>
>> Hey Sam, I've looked in the python.el code and it seems that it reuses
>> python-indent-def-block-scale for calculating an indentation.
>>
>> The default value is 2 which is why inside-parens indent doubles. Setting its
>> value to 1 fixes the issue.
>>
>> I also wonder why authors choose double indent for aligning function
>> arguments. Is this some kind of an oldschool code style? :) 
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> If I understand correctly (and I may well not -- I don't write much
> python), this is just a preference issue, and setting
> `python-indent-def-block-scale' to 1 fixes the issue?
>
> If that's what's recommended by the standards, should we flip the
> default to 1?
>
> I've added Augusto to the CCs; perhaps he has an opinion here.

I have no idea about what strong opinions other people may have here,
but after looking a bit into this I think 1 is probably a better default
for `python-indent-def-block-scale'. Here's what I found out:

The current default of 2 for `python-indent-def-block-scale' is meant to
produce this indentation style

```
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)
```

which is exactly as one can find in PEP-8.  Setting it to 1 produces

```
def long_function_name(
    var_one, var_two, var_three,
    var_four):
    print(var_one)
```

which is deemed wrong in that document.

However, the above formatting looks quite unfamiliar to me anyway.  I
usually see one of the following styles:

```
# By far the most common style in the Python source, and, I, think, the
# default style of YAPF
def long_function_name(var_one, var_two, var_three,
                       var_four):
    print(var_one)
```

which is insensitive to `python-indent-def-block-scale', or else

```
# Black does that, like it or not
def long_function_name(
    var_one, var_two, var_three,
    var_four
):
    print(var_one)
```

in which case a value of 1 for `python-indent-def-block-scale' is the
right thing.

Finally, the situation mentioned originally in this bug report seems to
be a glitch: an indentation rule that makes sense in a "for" statement
is being applied where a "for" appears in a list comprehension.  It's a
rather minor detail, I'd say.

bug#34268: 27.0.50; wrong indentation in python mode

[Lars Ingebrigtsen]

Augusto Stoffel <arstoffel@gmail.com> writes:

> I have no idea about what strong opinions other people may have here,
> but after looking a bit into this I think 1 is probably a better default
> for `python-indent-def-block-scale'. Here's what I found out:
>
> The current default of 2 for `python-indent-def-block-scale' is meant to
> produce this indentation style
>
> ```
> def long_function_name(
>         var_one, var_two, var_three,
>         var_four):
>     print(var_one)
> ```
>
> which is exactly as one can find in PEP-8.  Setting it to 1 produces
>
> ```
> def long_function_name(
>     var_one, var_two, var_three,
>     var_four):
>     print(var_one)
> ```
>
> which is deemed wrong in that document.

So it sounds like we need a different solution than just altering
block-scale, because it'd be nice if that continued to work, even if:

> However, the above formatting looks quite unfamiliar to me anyway.  I
> usually see one of the following styles:
>
> ```
> # By far the most common style in the Python source, and, I, think, the
> # default style of YAPF
> def long_function_name(var_one, var_two, var_three,
>                        var_four):
>     print(var_one)
> ```

Yeah, that looks more normal.

> Finally, the situation mentioned originally in this bug report seems to
> be a glitch: an indentation rule that makes sense in a "for" statement
> is being applied where a "for" appears in a list comprehension.  It's a
> rather minor detail, I'd say.

Right.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no