Auto indentation level should use black defaults instead of autopep8

[cdce8p]

Environment data

• Language Server version: 2023.6.21 (pre-release)
• Python version: 3.11

Code Snippet

def f() -> None:
    pass

Repro Steps

1. Move cursor in between parentheses to add function args
2. Press enter to write argument on new line

Expected behavior

The cursor should only auto-indent 4 spaces / one level. This was the behavior up until pylance 2023.4.30.
It's also what black uses when it formats code.

An indentation of 8 spaces is only used when the closing parentheses isn't on a new line.

Screen.Recording.2023-06-21.at.11.18.43.mov

https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html#how-black-wraps-lines

Actual behavior

The cursor is moved to an indentation level of 8 spaces.

Screen.Recording.2023-06-21.at.11.17.24.mov

Of note: Adding class parameter still only indents to 4 spaces.

Screen.Recording.2023-06-21.at.11.23.07.mov

Logs

--

[rchiodo]

Thanks for the issue but this is actually purpose. We follow the indentation rules as outlined in PEP8:
https://peps.python.org/pep-0008/#indentation

This specific example:

# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

Although we should probably do the same for classes too.

If you don't like the auto indent you can turn it off with this setting:

    "[python]": {
        "editor.formatOnType": false,
    }

Update: There's a new setting to turn off just Pylance's auto indent:

"python.analysis.autoIndent": false,

[erictraut]

This particular aspect of function formatting in PEP 8 is pretty archaic at this point. The black format is much more common in modern Python code. You might want to consider changing this behavior.

[frenck]

Couldn't say it better myself, fully agree 👍

[cdce8p]

Thanks for the issue but this is actually purpose. We follow the indentation rules as outlined in PEP8: https://peps.python.org/pep-0008/#indentation

This specific example:

# Add 4 spaces (an extra level of indentation) to distinguish arguments from the rest.
def long_function_name(
        var_one, var_two, var_three,
        var_four):
    print(var_one)

Although we should probably do the same for classes too.

As Eric mentioned already, this is rather outdated now. Furthermore, pressing Enter inserts a full new line with the ): on a separate line. This also doesn't match the PEP 8 style. I would really like to see this change being reverted. Esp. with type annotations, the preferred style nowadays is

def long_function_name(
    var_one: int,
    var_two: str,
    var_three: float,
    var_four: bool,
) -> None:
    print(var_one)

If you don't like the auto indent you can turn it off with this setting:

    "[python]": {
        "editor.formatOnType": false,
    }

I had set that already some time ago. The auto-indent happens anyway on Enter. Correctly so I would say. It's only the indent-amount that's the issue.

The vscode-python extension itself uses the correct indentation level. So I would have to disable pylance if I don't like that. That can't be the solution here, is it?

[rchiodo]

So I would have to disable pylance if I don't like that. That can't be the solution here, is it?

No just doing this should fix the problem:

    "[python]": {
        "editor.formatOnType": false,
    }

That's the setting that causes our indentation to be called.

[cdce8p]

So I would have to disable pylance if I don't like that. That can't be the solution here, is it?

No just doing this should fix the problem:

    "[python]": {
        "editor.formatOnType": false,
    }

That's the setting that causes our indentation to be called.

Interesting 🤔 I had set it globally for all languages but that didn't work. Why does the [python] specific overwrite work then?

[scholer]

Maybe it is just me, but I had a really hard time figuring out that this was the settings option I had to disable to make the editor not add additional indentation for function arguments.

I initially searched the Settings for "indent", because the problem was related to indentation. I then searched the Settings for "format", which did bring up the "Editor: Format On Type" setting, but it was unchecked, and I didn't initially notice the "(Modified elsewhere)". And even when I did notice, I figured that I generally want the editor to format as I type, I just don't want the editor to insert additional indentation for function arguments.

Having to disable "editor.formatOnType" just seems overly broad and radical, when it is just a single specific behavior I want to change.

I would have found it much more intuitive, if I'd had to locate a setting called something like "Add Extra Indentation for Function Arguments" or similar, that actually related to the specific behavior I was trying to fix.

For the record, I also meticulously went through the "Python" and "Pylance" settings sections in vscode, but didn't find anything. I only found out the misbehavior was caused by Pylance after I first disabled the Python extension and found that that fixed the issue, and then tried enabling "Python", but disabling "Pylance" (which is also disabled when you disable the "Python" extension).

[debonte]

I had set it globally for all languages but that didn't work. Why does the [python] specific overwrite work then?

@cdce8p, this is because Pylance's package.json specifies that editor.formatOnType should default to true for [python]. And setting it to false globally apparently doesn't affect that.

"configurationDefaults": {
    "[python]": {
        "editor.formatOnType": true,
        "editor.wordBasedSuggestions": false
    },

[debonte]

@scholer, I filed #5592.

[rchiodo]

Probably a bug in our 'experiment' framework. It sets this to true just for the python language.

[rchiodo]

The ): ending up on a new line is not done by the Python extension or the Pylance extension. That's how VS code works. You can repro it with a '.txt' file.

I can't seem to find a setting that controls that behavior though.

[rchiodo]

Moving to a discussion issue for upvotes.

[dkbarn]

Github doesn't provide a way to order discussions by number of upvotes. Are you able to share what the process is for vetting and prioritizing discussion tickets based on the number of upvotes they receive?

[rchiodo]

This is what we use:

[jkyeung]

Not sure if this is related, but it used to be that if you wanted to use a literal multiline string as an argument, the autoindent would try to line up the cursor just after the open-paren, but only on the first line. Subsequent lines would simply maintain the previous line's indentation. Now, it autoindents every line until the string is closed.

For example, suppose the first argument is a literal code snippet:

cursor.execute("""|)

When I press Enter, I get

cursor.execute("""
               |)

OK, fine, it's trying to align with the open-paren. But it used to be that I could just press Backspace to unindent as needed, and then go on typing, with each subsequent line only maintaining the previous line's indentation. For example, after I've unindented and gotten to this point:

cursor.execute("""
    select * from mytable|)

it used to be that pressing Enter would get me to this:

cursor.execute("""
    select * from mytable
    |)

But now, I actually get this:

cursor.execute("""
    select * from mytable
               |)

Is there a way to go back to just maintaining the previous line's indentation in that situation, without turning off all the other autoindentation, which for the most part is pretty good?

[rchiodo]

This situation seems like a bug to me. I don't believe this is on purpose. I'm going to create a separate issue for it.

#5415

[cdce8p]

This seems to be one of the most upvoted discussion at the moment. If the indentation style won't be changed, would you at least consider making it configurable?

Side note for PEP 8

Others have mentioned it already that most "modern" code doesn't follow it (anymore). I think it's useful to note here that the PEP only describes the style which should be used for the python/cpython repo itself. Whereas the Python ecosystem moves on to different style guides, it wouldn't make much sense / just create unnecessary workload to update the stdlib style.

https://peps.python.org/pep-0008/#introduction

[rchiodo]

This is our 'primary' list I guess you could say of upvoted items:

https://github.com/microsoft/pylance-release/discussions?discussions_q=sort%3Atop

There's still a bunch on there that we need to finish before anything happens with our format on type indentation.

Having a setting for mode might be a good idea.

I'm wary of which one we pick. Should it be black? Should it be prettier? Shouldn't we not pick anything and let another extension do formatting if you don't like our default? I believe that's why we have pep8 as our default now.

[dkbarn]

I think there are a few approaches Pylance could take on this issue --

1. Pylance is completely agnostic to code formatting (in which case it shouldn't enforce pep8 formatting) and relies on other extensions to handle this.
2. Pylance supports only a single formatting style, and that default style is the one that aligns with the majority of the Python community (which is black).
3. Pylance has multiple formatting styles to choose from, including black, prettier, pep8.

Any of these would be sensible IMO, but at the moment Pylance is not agnostic to formatting, it supports only a single formatting style, and that formatting style is not the one used by the majority of the Python community today.

[cdce8p]

I'm wary of which one we pick. Should it be black? Should it be prettier? Shouldn't we not pick anything and let another extension do formatting if you don't like our default? I believe that's why we have pep8 as our default now.

Even though I don't personally agree with all design choices, black seems to be the go to atm. Even ruff-format tries to match that style. That being said, I would be fine with either default (or even stay with PEP 8). If there is an option, it would be trivial to set it in the user config. That would likely address most concerns.

[rchiodo]

Maybe we just need a more obvious setting to turn our formatting off. This one seems wrong because other extensions wouldn't be able to implement format on type:

    "[python]": {
        "editor.formatOnType": false
    },

[rchiodo]

We added a new setting to make this more obvious (until we can get to a longer term solution):

"python.analysis.autoIndent": false

[rchiodo]

I don't think the Pylance extension should be implementing 'black' formatting for format on type. The black extension should.

[cdce8p]

(At least) I'm just talking about the indentation style here.

What's kind of frustrating from my POV is that it worked perfectly fine, until it was changed. I've disabled editor.formatOnType as suggested but am kind of missing the auto-indent feature.