You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
"IndentationError: unexpected indent" when evaluating indented blocks of code #2837
Relevant/affected Python packages and their versions: none
Actual behavior
Sending a selected Python code for evaluation in the Python terminal via Run Selection/Line in Python Terminal results in "IndentationError: unexpected indent" errors if the block of code is indented.
Example: evaluating the following selection results in an error because of the indentation of the whole block at 4 spaces:
Expected behavior
It would be useful if the evaluation of indented code worked regardless of it's position or level of indentation in the overall code (i.e. should be first deindented to a "base level" before sending to the terminal?).
As an example, the indented code above should be sent to the terminal as if it was the following (i.e. not indented):
I tend to work "bottom-up", evaluating/debugging smaller pieces of code that form more complex functions, and those individual pieces are obviously indented. This behavior makes this sort of workflow a little difficult.
Steps to reproduce
Use the following example code to test the behavior described above by evaluating the two commented blocks using Run Selection/Line in Python Terminal functionality.
def fn():
# block indented by 4 spaces -> results in an error
x, y = 10, 2
for i in range(x):
print(i ** y)
# block not indented -> correctly evaluated
x, y = 10, 2
for i in range(x):
print(i ** y)
I just briefly looked for a potential solution, at it seems that the issue could be solved by adding something like this as one of the pre-processing steps in this function?
Been struggling with this for an hour. Something this simple wouldn't run:
SOLUTION: Just make sure that the LAST line you run when using (Shift + Enter) is not indented. If the last line is indented, you will either get an indentation error or be shown your code again in output
Python is 100% unusable for me because of this, I have code that executes flawlessly in terminal, pycharm, spyder, jupyter, thonny, etc but nothing but indentation exceptions are being thrown in VSCode. The best part? I wrote it all in VSCode. It was executing fine and it started to get worse and worse, and now the code just doesn't even wanna go.
Disabled PyLint and it worked once, but now the behavior is back to indentation errors
Reacted by maxwell8888, James Otterson, Adam McCaughan, Econbrief, Giovanni Carmiol, kaseyriver11, h8hawk and lefig
Same issue as Giovanni Carmiol (@gcarmiol)
I also want to move to VSCode but this is making it hard. Right now I have to select a block....press Shift+Tab until I get it to the edge of the window, execute it....then tab it back to it's original indent.
Moreover... shift+tab and tab back is also giving me problems with flake8 indentation.
After i tab back i get: 'continuation line over-indented for visual indent' from flake8.
Can someone please post a proper workaround or pick up this issue?
I completely agree with all of this. I probably select-and-execute code blocks a hundred times a day with pycharm or spyder. And it's impossible with VSCode.
And I'm beginning to think I'm doing something wrong since there's so few complaints about this issue. What is everybody else doing? What debug workflow are others doing that doesn't hit this issue? Isn't everybody's code indented? Every Python script I write has almost every line indented except for the import lines at the top and the one if __name__ == '__main__' line.
What is everybody else doing? What debug workflow are others doing that doesn't hit this issue?
Funny that you mentioned debugging, since for me the integrated debugger is basically the only reason to use VSCode. It saved me on many occasions where I needed a proper debugger.
Otherwise, I have to say that VSCode-Python is pretty clunky: it's slow, there's no proper interactive shell, running code selections is pretty much impossible, the language server is still unusable and many operations just keep failing randomly (e.g. 'Run Python file in Terminal') works about 50% of the time for me).
However it does look promising. I keep hoping that it'll be more usable in the near future.
I totally agree with the points raised. This issue makes working with Python files in VS Code a real bore. Otherwise, it runs much faster for me than Spyder and I would love to keep using it, but this is becoming a real issue when evaluating sections of larger code chunks.
I think proposed solution is probably the best that can be done given the current architecture. The only thing missing (IMHO) would be to consider the indentation of the line where the selection starts. Knowing the original indent of the first line (when the entire line is not included in the selection -- e.g. spaces missed, some code parts intentionally omitted) would ensure the remainder of the selection is properly re-indented.
However, looking at the code I can see that only the selected text is passed; examining the original first line from the editor is not feasible without a larger refactor.
Activity
bodkan commentedon Oct 10, 2018
I just briefly looked for a potential solution, at it seems that the issue could be solved by adding something like this as one of the pre-processing steps in this function?
I have no experience with the codebase of this extension, but I'm happy to poke around more if you think this is something worth fixing.
DonJayamanne commentedon Oct 18, 2018
Before looking into this, we'd first need to fix #169
syagev commentedon Nov 14, 2018
A quick n dirty workaround for now is to "multi-select" the code block using ALT+SHIFT:

That still won't let you right-click > Debug:Evaluate but you can copy paste it in the debug window to get the code without any leading indentations.
tjaeel commentedon Jan 8, 2019
SOLVED:
Been struggling with this for an hour. Something this simple wouldn't run:
SOLUTION: Just make sure that the LAST line you run when using (Shift + Enter) is not indented. If the last line is indented, you will either get an indentation error or be shown your code again in output
SOLUTION EXAMPLE (this runs perfectly):
Don Jayamanne (@DonJayamanne) please fix this, thanks =)
martinpeck commentedon Jan 20, 2019
User has seen this issue and posted a question related to it on Stack Overflow. I assume this issue is the cause of this user's problems.
https://stackoverflow.com/questions/54276596/indentation-error-on-visual-studio-code-on-a-mac-again
nihirisuto commentedon Feb 10, 2019
Python is 100% unusable for me because of this, I have code that executes flawlessly in terminal, pycharm, spyder, jupyter, thonny, etc but nothing but indentation exceptions are being thrown in VSCode. The best part? I wrote it all in VSCode. It was executing fine and it started to get worse and worse, and now the code just doesn't even wanna go.
Disabled PyLint and it worked once, but now the behavior is back to indentation errors
scorpiocavalier commentedon Feb 19, 2019
This worked for me:
In Visual Studio 2017, go to Tools > Options > Text Editor > Python > Tabs.
Select "Keep tabs" and click OK.
Erase the current white spaces and indent as usual with Tab key.
The red lines should disappear.
11 remaining items
rubenl92 commentedon May 8, 2019
Same issue as Giovanni Carmiol (@gcarmiol)
I also want to move to VSCode but this is making it hard. Right now I have to select a block....press Shift+Tab until I get it to the edge of the window, execute it....then tab it back to it's original indent.
Moreover... shift+tab and tab back is also giving me problems with flake8 indentation.
After i tab back i get: 'continuation line over-indented for visual indent' from flake8.
Can someone please post a proper workaround or pick up this issue?
Thank you so much in advance!
nsymms commentedon May 8, 2019
I completely agree with all of this. I probably select-and-execute code blocks a hundred times a day with pycharm or spyder. And it's impossible with VSCode.
And I'm beginning to think I'm doing something wrong since there's so few complaints about this issue. What is everybody else doing? What debug workflow are others doing that doesn't hit this issue? Isn't everybody's code indented? Every Python script I write has almost every line indented except for the
importlines at the top and the oneif __name__ == '__main__'line.jjnurminen commentedon May 9, 2019
Funny that you mentioned debugging, since for me the integrated debugger is basically the only reason to use VSCode. It saved me on many occasions where I needed a proper debugger.
Otherwise, I have to say that VSCode-Python is pretty clunky: it's slow, there's no proper interactive shell, running code selections is pretty much impossible, the language server is still unusable and many operations just keep failing randomly (e.g. 'Run Python file in Terminal') works about 50% of the time for me).
However it does look promising. I keep hoping that it'll be more usable in the near future.
luabud commentedon May 9, 2019
Always de-dent to the first non-empty line in the selection
mikful commentedon May 23, 2019
I totally agree with the points raised. This issue makes working with Python files in VS Code a real bore. Otherwise, it runs much faster for me than Spyder and I would love to keep using it, but this is becoming a real issue when evaluating sections of larger code chunks.
DonJayamanne commentedon May 29, 2019
Prescribed solution:
textwrap.dedent)nsymms commentedon May 30, 2019
Thanks for addressing this, Don Jayamanne (@DonJayamanne).
I think proposed solution is probably the best that can be done given the current architecture. The only thing missing (IMHO) would be to consider the indentation of the line where the selection starts. Knowing the original indent of the first line (when the entire line is not included in the selection -- e.g. spaces missed, some code parts intentionally omitted) would ensure the remainder of the selection is properly re-indented.
However, looking at the code I can see that only the selected text is passed; examining the original first line from the editor is not feasible without a larger refactor.
ericsnowcurrently commentedon Jun 5, 2019
validated