Slow computer -> "Expected 0 positional arguments"

[s-banach]

Frequently, my editor gets filled with error messages like Expected 0 positional arguments (Pylance[reportGeneralTypeIssues]) which are totally spurious and go away when I reload the editor and/or edit and re-save the file. I think the issue is maybe that Pyright or Pylance is configured with some kind of timeout?

This has been happening for a year, so it's not particular to one version of the Pylance extension or python or VSCode.

To Reproduce
Edit a small-to-medium size python project on a slow processor, like an Intel 8565U in a cheap laptop with bad thermals and a bottom-of-the-line 256GB SSD.

Does anyone test pylance on a POS computer like this? It's all my work gives me.

[erictraut]

We've had reports of similar behaviors, but no one has been able to provide a repro case. If you have a set of steps that we can follow to repro the problem, we'd appreciate if you'd let us know.

[s-banach]

My best guess why the issue is "non deterministic" is that pyright is analyzing code at the same time that multiple other extensions (black, ruff) are changing that code. For example, I created test_program.py like this:

import shutil
from pathlib import Path

src_dir = Path(r"C:\Users\JHOPFENS\Documents\GitHub\pylance_repro") / "src"
if src_dir.exists():
    shutil.rmtree(src_dir)
src_dir.mkdir(exist_ok=True)


base = """def f0(x: int):
    return x

"""


def get_induction_case(n: int):
    top_line = f"def f{n}(x: int):\n"
    contents = ",".join(f"f{i}(x)" for i in range(n))
    next_line = f"    return sum([{contents}])\n\n"
    return top_line + next_line


with open(src_dir / "test_program.py", "w") as f:
    f.write(base)
    for n in range(1, 400):
        f.write(get_induction_case(n))

When I opened test_program.py, the type checker was correctly able to determine the types of the functions without issue.
Then I hit save, and the code formatter started adding in tabs and newlines. By the time the formatter finished, I was getting the Expected 0 positional arguments error at every invocation of f0().

[erictraut]

Are you using a multi-root workspace? We recently fixed a bug that could explain this behavior for multi-root workspaces.

[s-banach]

Sadly, no.

[blakeNaccarato]

This is happening to me, as well. Whenever a bunch of spurious "Expected 0 positional arguments" errors crop up (often in multiple files across the project), I trigger python.analysis.restartLanguageServer and they all go away.

Here's my system specs:

Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
AMD Radeon HD 7400
20.0 GB RAM
1TB Samsung 870 EVO SSD
Windows 10 Pro 22H2 19045.2965

Black runs on save. Pylance, Ruff, and Sourcery monitor for problems. I don't format or organize imports on save with Ruff. I do that separately with a keybind to ruff.executeAutofix. I've explicitly disabled source.fixAll and source.organizeImports in editor.codeActionsOnSave because those led to races/slowdowns of Black/Ruff/etc. stumbling over each other to format and such on save.

---

EDIT: My workaround has been to set python.analysis.diagnosticMode to openFilesOnly, and keep my Problems pane filtered down to Show active file only and Hide excluded files. The Problems counter still counts all problems, but visual clutter is reduced. Problems pane overwhelm comes from a few different places: spurious Pylance warnings when the system is under high load, Pylance warnings about stale temporary Jupyter notebook cells, and Ruff crawling into standard library files. These Problems pane issues all crop up sporadically, are hard to reproduce (probably involve races?), and involve the reporting of stale/out-of-scope Problems.

[pvaret]

This happens a lot in my projects. Is there a way I can dump the internal Pylance state when this issue occurs, so I could attach that to this ticket?

[bersbersbers]

I just hit this when opening all (40+) Python files in my non-multi-root workspace. I am also running a VM in parallel, which usually constrains my RAM quite a bit (16 GB in system, 8 GB allocated to VM), and with Edge and VS Code open, can easily lead to OOM errors.

[plsholdmybeer]

+1 happens all the time, pretty annoying, marks the file red as if there's errors, I need to edit the line anywhere, save, then undo, save and it's fixed.

[antoine-sac]

Happens regularly (but randomly) when I code on a remote Raspberry Pi 4.

Tip: I just hit ctrl+shift+P -> Python: Restart Language Server and it goes away.

Happy to send more info, logs etc if requested precisely.

[oefe]

My best guess why the issue is "non deterministic" is that pyright is analyzing code at the same time that multiple other extensions (black, ruff) are changing that code.

I see such spurious errors frequently in projects with pre-commit installed when I commit selectively only some files (or even only some lines in some files), while leaving other changes unstaged.

Pre-commit stashes these unstaged changes before running its checks, and restores them afterwards. So there are two changes to the affected files in a row, with typically just a few ten milliseconds between.

Oh, and I run pyright in the pre-commit hooks. This check never fails spuriously.

(The version of pyright used in pre-commit might not always be the same as in Pylance, as they are separately updated.)

This is in a normal project workspace (not multi-root), with about 100 Python files.

[debonte]

I've been trying off and on over the past couple weeks to reproduce this issue, but no luck. I've tried:

• Using black/ruff to cause edits as suggested by @s-banach

Then I hit save, and the code formatter started adding in tabs and newlines.

@s-banach, I was confused about this. You make it sound like you're watching the formatter make incremental changes to the file as it works it's way from top to bottom. I'm not aware of a way to configure black or ruff like this. They just calculate the changes they want to make and apply them all at once. If there's a way to make them format a document incrementally, let me know and I'll give it a try.

• Running Pylance remotely on a Raspberry (mine is a Pi 4B with 8GB of RAM) by as suggested by @antoine-sac

• Using pre-commit to cause edits (stash/unstash) as suggested by @oefe

I also tried combining these approaches running black and pre-commit on my Raspberry Pi.

If any of you are able to reproduce this and provide a log as described under "Filing an issue" in the troubleshooting guide, that would be appreciated.

[oefe]

In my case, it's on a MacBook Pro (Intel), so it may not necessarily be tied to a slow computer.

I can give trace logging a try, although I'm a bit concerned about the warning about performance. As the issue happens only rarely, I would have to have trace logging enabled for possibly a long time

[debonte]

In my case, it's on a MacBook Pro (Intel), so it may not necessarily be tied to a slow computer.

I also tried to repro this on my primary dev machine which is pretty fast, 6 cores, and 64 GB of RAM. No luck there either.

I can give trace logging a try, although I'm a bit concerned about the warning about performance. As the issue happens only rarely, I would have to have trace logging enabled for possibly a long time

I run with python.analysis.logLevel set to Trace all the time. Admittedly, I'm doing less Python development than you -- my primary language is TypeScript. But the perf doesn't bother me. I think the main hit may be on indexing at startup.

[oefe]

I was editing lines 184..300(ish) of file "sequence_commands.py", pressed Cmd+S to autosave and autoformat (using Ruff), when suddenly two spurious Pylance errors popped up further down in the same file:

Here's the content of the "Problems" window:

[{
	"resource": "/Users/moefelei/Repos/cli-prototype/src/ardia/cli/sequence_commands.py",
	"owner": "_generated_diagnostic_collection_name_#5",
	"code": {
		"value": "reportCallIssue",
		"target": {
			"$mid": 1,
			"path": "/microsoft/pyright/blob/main/docs/configuration.md",
			"scheme": "https",
			"authority": "github.com",
			"fragment": "reportCallIssue"
		}
	},
	"severity": 8,
	"message": "No parameter named \"overwrite\"",
	"source": "Pylance",
	"startLineNumber": 489,
	"startColumn": 9,
	"endLineNumber": 489,
	"endColumn": 18
},{
	"resource": "/Users/moefelei/Repos/cli-prototype/src/ardia/cli/sequence_commands.py",
	"owner": "_generated_diagnostic_collection_name_#5",
	"code": {
		"value": "reportCallIssue",
		"target": {
			"$mid": 1,
			"path": "/microsoft/pyright/blob/main/docs/configuration.md",
			"scheme": "https",
			"authority": "github.com",
			"fragment": "reportCallIssue"
		}
	},
	"severity": 8,
	"message": "No parameter named \"comment\"",
	"source": "Pylance",
	"startLineNumber": 490,
	"startColumn": 9,
	"endLineNumber": 490,
	"endColumn": 16
}]

This happened at around 2024-04-09 13:20.

Logs: Python Language Server.log.zip.

[debonte]

I was editing lines 184..300(ish) of file "sequence_commands.py", pressed Cmd+S to autosave and autoformat (using Ruff), when suddenly two spurious Pylance errors popped up further down in the same file...

Thanks @oefe.

Did you make any changes related to the overwrite and comment parameters shortly before these diagnostics appeared? For example, had you recently added those parameters to the add_raw_data function, or renamed them? Had you made changes around the declaration of add_raw_data that might have caused Ruff to reformat the function declaration?

Could you try setting "python.trace.server": "compact" and sending a log if/when it repros again? This will log the LSP traffic between Pylance and VS Code.

Please note that this traffic includes the content of your files as you open/change them. If you're not comfortable posting a log of that sort here, would you be willing to share it with me privately? I would only look at it in the context of investigating this issue and would delete it immediately afterwards.

[oefe]

Did you make any changes related to the overwrite and comment parameters shortly before these diagnostics appeared? For example, had you recently added those parameters to the add_raw_data function, or renamed them? Had you made changes around the declaration of add_raw_data that might have caused Ruff to reformat the function declaration?

No. Both add_raw_data and the code calling it have not been changed for a long time. All changes were further up in the file, as mentioned. The Ruff reformat may have introduced a handful of additional line breaks.

I've set python.trace.server, let's see when it happens again.

[github-actions]

Hey @debonte, this issue might need further attention.

@s-banach, you can help us out by closing this issue if the problem no longer exists, or adding more information.

[oefe]

@debonte It happened again. This time, the problem was apparently triggered by renaming a python file. (The file is dynamically loaded, so the rename should not have caused any validation errors).

Suddenly errors about typer.Option popped up in a few files. (But note that most occurrences of typer.Option were not affected; there are a total of 93 occurrences of typer.Option in 24 files in the project.)

I saved the log as well as the content of the Problems window. Let me know how I can send it to you.

(The log doesn't contain a "Pylance language server XXX (pyright xxx) starting" message. Apparently, the output buffer has a limited size. So I copied everything starting around 21:00, which is when I resumed editing after being away from the computer for a while.)

N.B. I have done a lot of renames/moves earlier today without any problems. So it is really a rare occurrence.

[debonte]

Let me know how I can send it to you.

Thanks @oefe! If you're uncomfortable posting the log here (large files can be dragged into a comment as attachments), you can email it (or a link to it) to me at erikd at microsoft dot com.

[oefe]

Thanks. I sent you an email with the logs

[debonte]

I'm optimistic that microsoft/pyright#8118 will fix the issue that @oefe is seeing. Looks like it'll ship in tonight's Pyright release and be in Pylance later this week.

[rchiodo]

This issue has been fixed in prerelease version 2024.6.100, which we've just released. You can find the changelog here: CHANGELOG.md