Spyder: Spyder 4.1.4: Linting not working, intentation bug

[lorenzznerol]

Issue Report Checklist

• [x] Searched the issues page for similar reports
• [ ] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
• [x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda) --> brand new 4.1.4
• [ ] Could not reproduce inside jupyter qtconsole (if console-related)
• [x] Tried basic troubleshooting (if a bug/error)
  
  
  
  • [x] Restarted Spyder
  
  
  • [x] Reset preferences with spyder --reset --> it is a brand new installation on a new computer
  
  
  • [x] Reinstalled the latest version of Anaconda --> brand new installation
  
  
  • [ ] Tried the other applicable steps from the Troubleshooting Guide
  
  
• [x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description

Linting is not working. Code completion works.

What steps reproduce the problem?

The issue appeared after quite some time in the one file - call it file1, but I was working on file2 all the time.

As to file2:
file2 instead had no errors, but I also do not remember any linting at all there from the start, I have not checked it. After restart, there were about a dozen yellow underlinings per about 50 lines. It was saying something like "cannot give you any help here", and when I clicked on it, all of the yellow underlinings went away and did not come back.

As to file1:
I had not done anything more than changing slightly 3 lines here, commenting out 2 of them:

df.columns
df.head(1).to_string()
df.set_index(['time'], inplace = True)

I commented 2 code lines during some testing, and then only the errors appeared. That is why it may be reproducible.

The strange thing is that the comment signs were set right at the start of the line, although they should have been indented by one tab distance, because I was in the main block that starts with "if __name__ == '__main__':".

First the already known bug documentation.

Against the announcement, I have the issue again even in version 4.1.4 (Windows 10 Home, 64bit). I do not see a working linting: there are errors reported that should not be there. At least the code completion works.

Examples.
Here, "x" should be unknown and underlined, I have changed it to parameter "a" on purpose, yet it is not underlined:

Here you see an indentation error and afterwards an underlined comment, although both lines are OK. Mind that the comment sign should have been one tab to the right instead, because I was in the block of "if __name__ == '__main__':"

The strange behaviour came up only after quite some time (but as said above, I was not working on the file, that is why this information might be irrelevant).

If I comment them now, the comment sign is set with the right indentation (one tab right from the editor border). But there is a new indentation issue afterwards.

If you use ctrl+1 and then toggle back, the comment leaves one space more than the full revert would need.

1) Starting point

2) after ctrl+1

3) after ctrl+1

3_error) (the error is usually this one. I have seen one different error once, which was also very general and I forgot)

4) after ctrl+1

5) after ctrl+1

6) after ctrl+1

7) after ctrl+1

8) after ctrl+1 (indentation error stops after 2 shifts here)

Now I check what is happening when I mark the block and press shift-tab to get the code indentation aligned to the editor border. First I comment the other 2 lines (probably not even needed):

Then I mark the 3 lines and press shift+tab

If I instead just pressed tab at that point, the indentation change would be as expected

Perhaps, the indentation is the whole issue, causing the linting not to work as a consequence. Some lines seem not to be recognised by Python as the standard indentation, it is probably a mixture of a tab-rooted indentation and an indentation based on spaces due to a wrongly aligned comment start (comment after ctrl+1 starts on the left border, even though code block is indented, later the comment begins to start in alignment with the codeblock, and then the shift+tab also works as expected).

What is the expected output? What do you see instead?

Expected:

• correct indentation at one tab right from the border when using ctrl+1
• pressing ctrl+1 twice should bring the first indentation back
• no error underlining in a comment line even when the comment is starting not aligned with the other indentations of that block
• in a function when using x in the function body, when x is not used as an argument of the function, x should be underlined as unknown
• When I press shift+tab, any line that has spaces before its text start should be "back-indented" by one tab distance

What I see: see screenshots above

Versions

• Spyder version: 4.1.4
• Python version: 3.7.7
• Qt version: 5.9.6
• PyQt version: 5.9.2
• Operating System name/version: Windows 10 Home / version 2004

Dependencies

Mandatory:

atomicwrites >=1.2.0 : 1.4.0 (OK)
chardet >=2.0.0 : 3.0.4 (OK)
cloudpickle >=0.5.0 : 1.5.0 (OK)
diff_match_patch >=20181111 : 20200713 (OK)
intervaltree : None (OK)
IPython >=4.0 : 7.16.1 (OK)
jedi =0.17.1 : 0.17.1 (OK)
nbconvert >=4.0 : 5.6.1 (OK)
numpydoc >=0.6.0 : 1.1.0 (OK)
paramiko >=2.4.0 : 2.7.1 (OK)
parso =0.7.0 : 0.7.0 (OK)
pexpect >=4.4.0 : 4.8.0 (OK)
pickleshare >=0.4 : 0.7.5 (OK)
psutil >=5.3 : 5.7.0 (OK)
pygments >=2.0 : 2.6.1 (OK)
pylint >=1.0 : 2.5.3 (OK)
pyls >=0.34.0;<1.0.0 : 0.34.1 (OK)
qdarkstyle >=2.8 : 2.8.1 (OK)
qtawesome >=0.5.7 : 0.7.2 (OK)
qtconsole >=4.6.0 : 4.7.5 (OK)
qtpy >=1.5.0 : 1.9.0 (OK)
rtree >=0.8.3 : 0.9.4 (OK)
sphinx >=0.6.6 : 3.1.2 (OK)
spyder_kernels >=1.9.2;<1.10.0 : 1.9.2 (OK)
watchdog : None (OK)
zmq >=17 : 19.0.1 (OK)

Optional:

cython >=0.21 : 0.29.21 (OK)
matplotlib >=2.0.0 : 3.2.2 (OK)
numpy >=1.7 : 1.17.0 (OK)
pandas >=0.13.1 : 1.0.5 (OK)
scipy >=0.17.0 : 1.5.0 (OK)
sympy >=0.7.3 : 1.6.1 (OK)

[ccordoba12]

@lorenzznerol, thank you for all the detail, but (as I mentioned in StackOverflow and also on issue #10993), we need a simple and reproducible way to generate your problem. That's what (after many months of going in circles) @OverLordGoldDragon did for us two months ago, which led to a lot of improvements in linting and code completion in 4.1.4.

In the meantime, please select the entry shown after clicking on status bar widget called "LSP Python" to restart the server and keep working as usual.

[lorenzznerol]

I found out the reason for my errors. They are caused by myself, the version 4.1.4 works. I had changed the tabs to be 4 spaces, while still also having real tabs somewhere, and some spaces followed by smaller tabs sometimes. I do not understand what has happened there, must be something that happened during testing the linting in earlier versions when I replaced tabs with spaces and back using Regex. It could also come from using vscode and PyCharm during testing, switching back an forth, changing the 4 spaces to tabs there as well for some lines. Some uncleaned testing probably caused all of the formatting errors in the end. I have now replaced all \t (and other strange even longer tabs) that I could find with 4 spaces, which is the best practice and the Spyder default anyway.

Example of my formatting error. When I copy a perfectly aligned code and paste it in an editor, it has lost some alignment. Only the lines that had a "bad tab" in it had the strange comment-out-comment-in-go-one-position-to-the-right problem of the above screenshots.

if __name__ == '__main__':
    blnCreateGraphs = False
    filename = "C:\\Users\\Admin\\Documents\\test.bson"
        bs = open(filename, 'rb').read()
        data = bson.decode_all( bs )

while the expected insertion would be:

if __name__ == '__main__':
    blnCreateGraphs = False
    filename = "C:\\Users\\Admin\\Documents\\test.bson"
    bs = open(filename, 'rb').read()
    data = bson.decode_all( bs )

####

Now the linting works as well. This issue can be closed, sorry for the wrong alarm, I will change StackOverfow https://stackoverflow.com/questions/59250636/how-to-turn-on-off-code-analysis-features-in-spyder-4 accordingly.

I thought for a moment that there is a small rest of an issue, that a local variable is mistakenly accepted though not passed to the function.

But this is wrong alarm. Everything is ok. In the following example, b is passed, but a is assigned to y. There is no linting because a is a global variable. b is not used, but that does not have to be linted.

def test (b):
    y = a
    return y

if __name__ == '__main__':
    a = 1
    test(2)

I am realizing very late now that, when everything in the main is a global variable and I have accidentally defined "a" somewhere far down in the main script, "a" is also known in the local variables of the function. I have only checked the linting by changing the locally assigned variable to "a" (which should be the wrong assignment on purpose). I never got a linting because "a" was global.

Thus, there is no issue anymore from my side.

[ccordoba12]

Hey @lorenzznerol, I'm really glad you found the cause of your linting issues, and even more to read our linter bugs seem to be a thing of the past.

I hope you really enjoy using Spyder from now on.

[lorenzznerol]

Yes it is good that this was wrong alarm. At the moment, I am fine with it, must be partly the funny reason that I can run a selection / line just with F9 instead of three buttons on PyCharm ;). And I am not the one to change the shortcuts. vscode is unusable since a month, it cannot run a selection / line at all. Spider has also a colourful and nice default editor and editor structure, keep up the good work.

[ccordoba12]

Thanks for your kind words @lorenzznerol, we'll do!