If you regularly use Visual Studio Code for Python development and have experience with the Visual Studio Code Python Debugger extension, I would really appreciate your thoughts.
When developing internal tools, I try to catch issues like type errors as early as possible—ideally before runtime. To achieve this, I use type-checking tools such as Pyrefly.
However, the Python Debugger does not stop or react when such errors are detected. If I overlook the type-checking results and proceed with debugging, I only encounter the error later during execution, which ends up costing additional time.
To address this, I submitted a pull request:
The idea is simple: if type-checking errors are detected, the debugger would pause and prompt the developer to decide whether to continue debugging. I believe this could help reduce time wasted due to typos or similar issues.
That said, the pull request has not been merged so far. This makes me wonder whether this feature is not considered valuable by most users.
I’d love to hear your perspective:
Would this improvement be useful to you, or do you feel its benefit is limited?
A dialog box is a major interruption, taking you out of the flow, and possibly requiring extra effort to get rid of (especially since it isn’t clear what the Esc key will do here, will it abort debugging?). I would definitely not use this option.
I’m referencing the behavior of the JavaScript/TypeScript debugger.
This option, by default, doesn’t affect debugging even if errors are found.
It’s only available to developers with specific needs, such as those who have already installed type-checker and found errors, and those who want to fix issues before execution for greater stability.
Type checking is optional. I say this as a strong supporter of type checking.
So it must be an opt-in behaviour, which I could to today with a task-sequence in vscode (run my preferred linting tools before the debugger task)
Also IIU your proposal would mix responsibilities from type checkers into the debugger, which then raises the question which type checker behavior and configuration would be used for that decision?
(Though there is active work on improving conformance, there are notable differences and styles)
I ask this as I very frequently work on project that use a mix of Python and MicroPython, which requires a rather complex set of configuration for both static type checking, and debugging. While that won’t be the norm, it does highlight the problem with mixing responsibilities.
Initially, this feature wasn’t tied to any checkers.
It’s because each checker has different strengths,
and might detect errors that other checkers miss.
The errors detected by one or more checkers are then compiled into a list.
This feature prompts the user to correct the source code if any errors are detected in this list, or conversely, to adjust the checker settings/level.
Because I’m used to statically typed languages (C#/Java),
stopping debugging when it fails to compile feels natural.
But your reminder made me realize that this feature should be the responsibility of the IDE.
Currently, I’ve also set checkers in VSCode’s launch.json and tasks.json.
However, I’ve found that I have to pre-configure them individually for each project. The number of checkers required determines the number of checkers needed.
Also, if an checker doesn’t support CLI functionality (like Pylance), it can’t be added.
Perhaps VSCode will have a more convenient way to add checkers in the future without manually modifying launch.json and tasks.json. That would be great.
Pyright is the CLI version of Pylance, it accepts the same configuration
But in Python perfectly good bugless code can fail a static type check. So should that stop you from running the debugger?
Lastly there is an existing VSCode api that can access the diagnostics that are found vscode.languages.getDiagnostics()
Perhaps you could use that to simplify your confirmation. But I think that is outside the scope of this forum.
Thanks for letting me know. I was just thinking that if “even bug-free code might fail static type checking,” then the situation would be the same in both the GUI and CLI. I can accept this, and I’m not opposed to adjusting the type checker settings, disabling it, or using a different type checker. However, I’m wondering if there’s a way to simplify the VSCode type checker settings—an out-of-the-box approach that syncs with profiles and doesn’t require setting up a separate tasks.json file for each project.