We’re excited to announce the November 2023 release of the Python and Jupyter extensions for Visual Studio Code!
This release includes the following announcements:
- Improvements to
Shift + Enterrun line in terminal - Deprecated built-in linting and formatting features
- Improvements to Python linting extensions
- Reconfiguration of test output
- Virtual environment deactivation help
- Announcing Python in VS Code release videos
If you’re interested, you can check the full list of improvements in our changelogs for the Python, Jupyter and Pylance extensions.
Improvements to Shift + Enter run line in terminal
The Python extension is working on improving the behavior of sending code to the Python REPL (Shift+Enter) when no code has been explicitly selected to run. Previously, when you placed your cursor on a line of Python code and pressed Shift+Enter, the Python extension would send the exact line contents to the REPL, even if it would fail, for example, due to being part of a multi-line command.
With our new experimental Smart Send feature, the Python extension will send the smallest runnable block of code surrounding the line where your cursor is to the REPL for execution. This ensures that only complete and executable sections of code are sent to the REPL. The cursor will also be automatically placed to the next executable line, to provide a smooth experience when executing multiple chunks iteratively.
To try it out, you can add the following User setting: "python.experiments.optInto: ["pythonREPLSmartSend"]. While this feature is currently behind an experiment, we expect it to be the default behavior in the future. If you have feedback or suggestions on how we can further improve this feature, please let us know!
Deprecated built-in linting and formatting features
With all the ongoing work and improvements we have been making to the linting and formatting extensions in VS Code for the last year, we have deprecated the built-in linting and formatting features that are shipped within the Python extension. This includes all the linting and formatting commands as well as settings (python.linting.* and python.formatting.*). We recommend you to remove these deprecated settings if you are still using them, and use the linting and formatting extensions instead, as they offer a more configurable and flexible experience.
If you were using a linter or formatter that does not yet have an extension, you can create linter or formatter VS Code extensions for your favorite Python tool! Check out our Python Tools Extension Template for a quick start.
Furthermore, we would like to highlight the community-contributed Ruff extension. Ruff is a Python linter written in Rust and it supports various linters such as pyflakes, pycodestyle, pydocstyle, and more! They have also recently enabled support for using Ruff as a formatter in VS Code ("[python]": { "editor.defaultFormatter": "charliermarsh.ruff" }). Try it out for your Python linting and formatting support in VS Code!
Improvements to Python linting extensions
We have made several improvements to the linting extensions our team supports to allow for an even more configurable and flexible experience with your favorite Python tools.
The Pylint, Mypy and Flake8 extensions now offer settings that allow you to specify glob patterns for files that you wish to exclude from linting. This can be useful if you are working with a large codebase with many sub-projects, and want to exclude certain folders from being linted.
These settings are "pylint.ignorePatterns", "mypy-type-checker.ignorePatterns" and "flake8.ignorePatterns", respectively.
These extensions also support cwd settings, which allows you to specify the working directory for the linter. This setting has been updated to support the variable ${fileDirname}, so the working directory can be dynamically set to the parent folder of the file you have open in the editor. This can be particularly useful if you are working with mono-repos, and want the linter’s working directory to be dynamically updated as you open files from different sub-projects. These settings are "pylint.cwd", "mypy-type-checker.cwd" and "flake8.cwd", respectively.
We have also changed the default value of the "mypy-type-checker.preferDaemon", only applicable to the Mypy extension. Previously, it was set to true, which meant that the Mypy daemon would be used by default. After receiving feedback, we have changed the default value to false. If you are wondering which value would be best for you, our recommendation is to use the Mypy daemon if you enabled the Mypy reporting scope to be the entire workspace ("mypy-type-checker.reportingScope": "workspace") for performance reasons. Otherwise, if the reporting scope is set to the current file, we recommend you use the Mypy executable that is shipped with the extension.
Reconfiguration of test output
We’ve made significant improvements to how you can view and interact with the Test Output in the Python extension when the pythonTestAdapter experiment is enabled, which we announced a few months ago. Previously, output from test discovery and execution was inconsistently scattered across the Python Test Log output channel and the Test Results panel, with some information being duplicated in both places. To consolidate the experience, we are now displaying output related to test execution in the Test Results panel, and test discovery in the Python output channel. To learn more see our related wiki.
This new approach also supports colorization in the output if you are using Pytest and set "python.testing.pytestArgs": ["--color=yes"] in your Workspace settings.json. Colorization only works for test execution in the Test Results panel and will not work for discovery or for output in the Python Test Log panel.
