HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
microsoft
pylance-release
Python2020–2026
microsoft / pylance-release

pylance-release

Documentation and issues for Pylance

31Distinct people
33Mentions
0Explicit recommenders
2.2KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Documentation and issues for Pylance

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

First steps in bare-metal programming using UEFI direct repository linkDebated

The discussion centers on the difficulties of UEFI development, with participants debating whether the environment constitutes true bare-metal programming and criticizing its reliance on outdated standards like UTF-16 and VFAT. While some users find value in existing libraries and resources, others argue that UEFI's design choices create unnecessary complexity compared to alternatives like Multiboot2 or coreboot.

57 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4

Mentions over time

HN mentions by year33 dated mentions

Observed mentions: 2020-07-03 16:13:33 UTC to 2026-10-26 23:22:14 UTC.

02468102020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 7 mentions; 3 submissions, 4 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 10 mentions; 1 submissions, 9 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments20232024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2025-01-01 00:00:00 UTC to 2026-01-01 00:00:00 UTC (exclusive): 3 mentions; 0 submissions, 3 comments2026-01-01 00:00:00 UTC to 2027-01-01 00:00:00 UTC (exclusive): 3 mentions; 1 submissions, 2 comments. Incomplete calendar period.2026*

* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC734
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC1019
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC101
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC303
20252025-01-01 00:00:00 UTC2026-01-01 00:00:00 UTC303
2026 (partial)2026-01-01 00:00:00 UTC2027-01-01 00:00:00 UTC312

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
Pylance Fast, feature-rich language support for Python This repository is for providing feedback and documentation on the Pylance language server extension in Visual Studio Code. You can use the repository to report issues or submit feature requests. The Pylance codebase is not open-source but you can contribute to Pyright to make improvements to the core typing engine that powers the Pylance experience. Pylance is the default language support for Python in Visual Studio Code and is shipped as part of that extension as an optional dependency. The Pylance name is a small ode to Monty Python's Lancelot who was the first knight to answer the bridgekeeper's questions in the Holy Grail. Quick Start Install the Python extension from the marketplace. Pylance will be installed as an optional extension. Open a Python (.py) file and the Pylance extension will activate. Note: If you've previously set a language server and want to try Pylance, make sure you've set "python.languageServer": "Default" or "Pylance" in your settings.json file using the text editor, or using the Settings Editor UI. Features Pylance provides some awesome features for Python 3, including: Docstrings Signature help, with type information Parameter suggestions Code completion Auto-imports (as well as add and remove import code actions) As-you-type reporting of code errors and warnings (diagnostics) Code outline Code navigation Type checking mode Native multi-root workspace support Jupyter Notebooks compatibility Semantic highlighting Generate Dependency File command for workspace roots, Explorer folders, and Python scripts (Pylance: Generate Dependency File) Toggle Block Comment command for Python (Pylance: Toggle Block Comment) Install Matching Type Stubs command that finds and installs type stub packages for your installed dependencies (Pylance: Install Matching Type Stubs) Copilot Chat skills for fact-grounded Python help, type inference, inline type annotations, finding reviewed third-party stubs, stub authoring, Pylance docs, refactoring, profiling, improving Pylance type-evaluation performance, and adding or dropping Python version support See the changelog for the latest release. Settings and Customization Pylance provides users with the ability to customize their Python language support via a host of settings which can either be placed in the settings.json file in your workspace, or edited through the Settings Editor UI. python.analysis.languageServerMode Offers predefined configurations to help users optimize Pylance's performance based on their development needs. It controls how many IntelliSense features Pylance provides, allowing you to choose between full language service functionality or a lightweight experience optimized for performance. Default value: default Available values: light default (default) full Description: default: Provides a balanced experience with many useful features enabled by default. It ensures that the language server delivers sufficient functionality for most users without overloading the system. Advanced features can be enabled as needed, allowing for further customization at the cost of performance. light: Designed for users seeking a lightweight, memory-efficient setup. This mode disables various features to make Pylance function more like a streamlined text editor. Ideal for those who do not require the full breadth of IntelliSense capabilities and prefer Pylance to be as resource-friendly as possible. full: Designed for users seeking the most extensive feature set. This mode enables most of Pylance's features, offering the richest IntelliSense experience. Ideal for those who want access to the full range of available functionality. Individual settings can be configured to override the defaults set by languageServerMode. Default settings based on mode are: Mode light default full python.analysis.exclude ["**"] [] [] python.analysis.useLibraryCodeForTypes false true true python.analysis.enablePytestSupport false true true python.analysis.indexing false true true python.analysis.userFileIndexFollowSymlinkedFolders true true true python.analysis.autoImportCompletions false false true python.analysis.showOnlyDirectDependenciesInAutoImport false false true python.analysis.packageIndexDepths See settings below python.analysis.regenerateStdLibIndices false false true python.analysis.userFileIndexingLimit 2000 2000 -1 python.analysis.includeAliasesFromUserFiles false false true python.analysis.inlayHints.functionReturnTypes false false true python.analysis.inlayHints.pytestParameters false false true python.analysis.supportRestructuredText true true true python.analysis.supportDocstringTemplate false false false python.analysis.nodeExecutable "" "" "auto" python.analysis.typeCheckingMode Used to specify the level of type checking analysis performed. Default: off. Note that the value of this setting can be overridden by having a pyrightconfig.json or a pyproject.toml. For more information see this link. Available values: off: Most type-checking diagnostics are disabled; unresolved imports/variables diagnostics are produced. basic: All rules from off + basic type checking rules. standard: All rules from basic + standard type checking rules. strict: All rules from standard + strict type checking rules. You can refer to pyright documentation to reference the default type checking rules for each of the type checking modes. Performance Consideration: Setting python.analysis.typeCheckingMode to off can improve performance by reducing diagnostic checks, especially in large codebases. python.analysis.diagnosticMode Used to allow a user to specify which files receive full diagnostics. Available values: workspace openFilesOnly (default) Performance Consideration: Setting python.analysis.diagnosticMode to openFilesOnly limits full diagnostics to open files, reducing checking in large workspaces. Imported dependencies ca
Read the full README on GitHub

What Hacker News says

33 sources
> why this exists https://docs.basedpyright.com/v1.40.2/type-server/ > The "type server protocol" is a desperate attempt from microsoft to prevent pylance from becoming obsolete by outsourcing its type checking to other language servers like basedpyright, ty or pyrefly -- while continuing to keep certain language server features exclusive to pylance. > This protocol benefits nobody except microsoft. It adds needless complexity to any language server that chooses to support it. Basedpyright does not support it and strongly advises other language servers to avoid supporting it as well. > For more info see here https://github.com/microsoft/pylance-release/discussions/718... and here https://github.com/astral-sh/ty/issues/1190#issuecomment-337...
In Type Server Protocol
The pylance team has started exploring this, namely whether it makes sense to have an API for type checkers that is not the LSP, as language servers have a somewhat different goal in which type checking/inference is an enabling technology. This could allow multiple different language servers to be built on top of different type checkers (and the type checkers can run out-of-proc, so implementation languages can be different). https://github.com/microsoft/pylance-release/discussions/718...
In Ty: A fast Python type checker and language server
I was a longtime user of Sublime Text and switched to VSCode because of Remote Development and Pylance. Everything else is pretty much fine and Sublime has always had better performance, though these days having support for AI integration (a la Copilot) is also necessary for me. I tried Zed recently because it has remote support and AI integration, but the Python integration is limited to Pyright so I gave up temporarily (I guess I can recreate Pylance using this doc: https://github.com/microsoft/pylance-release/blob/main/USING...).
In I still like Sublime Text
I think it is "better" to go with the flow. I can't see TS competing for the data analysis niche any time soon! Maybe try Pixi? [1] Python programming enjoyability really increased for me after using Pixi for dependencies, VSCode+Pylance [2] for editing, and Ruff [3] for formatting. Pixi can install both python and dependencies _per project_. Then, I add this to .vscode/settings.json: { "python.analysis.typeCheckingMode": "strict", "python.defaultInterpreterPath": ".pixi/envs/default/bin/python3" } and I'm all set! -- 1: https://pixi.sh 2: https://github.com/microsoft/pylance-release#readme 3: https://docs.astral.sh/ruff/
In NumPy 2.0
One of the things that comes to mind here is the fact that the default Python extension for VS Code is, perhaps surprisingly to many, not open source. https://github.com/microsoft/pylance-release While it's possible to fork VS Code, it is not possible to fork VS Code and provide a seamless onramp towards a Python editing experience that is fully open source, because users are used to the nuances of the closed-source Pylance experience in VS Code proper. You could use the minified/compiled Pylance plugin in your fork, but you'd have no way to expand its capabilities to new hooks your fork provides. Microsoft's development process would always be able to move faster than a fork, because it could coordinate VS Code internal API development with its internal Pylance team, and could become incompatible with forks at any time. It's worth re-rea
Read the rest
ding the quote from J Allard in https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguis... with this modern example in mind. (Also worth mentioning https://github.com/detachhead/basedpyright?tab=readme-ov-fil... which is a heroic effort to derisk this, but it's an uphill battle for sure!)
In Open source versus Microsoft: The new rebellion begins
You can switch the extension marketplace, but Microsoft uses DRM in their extensions to prevent them from running with non-proprietary builds [1]. Pylance, their Python LSP, is one notable example [2]. Their earlier Python LSP was open source, but the community forks have lost a lot of the wind in their sails because such a large portion of developers use VC Code without realizing or caring that the LSP is DRM-laden and closed source. I believe the traditional term for this is embrace, extend, extinguish. [1] - https://parsiya.net/blog/2021-12-20-rce-in-visual-studio-cod... [2] - https://github.com/microsoft/pylance-release/issues/746
In VSCodium – Open-source binaries of VSCode
Maybe they produce the same results (I don't know), but Pylance using Pyright doesn't mean that Pylance is Pyright. One important difference in this case is that while "Pylance leverages Microsoft's open-source static type checking tool, Pyright" [1], Pylance itself is not open source. In fact, the license [2] restricts you to "use [...] the software only with [...] Microsoft products and services", which means that you are not allowed to use it with a non-Microsoft open source fork of VS Code, for example. The license terms also say that by accepting the license, you agree that "The software may collect information about you and your use of the software, and send that to Microsoft" and that "You may opt-out of many of these scenarios, but not all". [1] https://github.com/microsoft/pylance-release [2] https://marketplace.visualstudio.com/
Read the rest
In Writing Python like it's Rust
The example is not .NET in general, but that specific event when Microsoft reneged on open development tooling[1]. For some people, that was the moment they stopped trusting "new Microsoft" to keep their word (though for me, it was when the Python language server was replaced with a DRM-locked, LSP-noncompliant one[2] a bit before that; unlike with .NET hot reload, they didn't backtrack there). I can think the company makes great open .NET tools and at the same time not trust them to close those down on a whim. Does anyone know where the open xlang implementation of MIDL[3] went, by the way? (Unlike the original 1990s MIDL, you can't reimplement this one from the language grammar in the docs, because there is no language grammar in the docs[4].) [1] https://dusted.codes/can-we-trust-microsoft-with-open-source and links there [2] https://g
Read the rest
ithub.com/microsoft/pylance-release/issues/4 [3] https://github.com/microsoft/xlang/pull/529 [4] I vaguely remember a GitHub issue where a Microsoft employee explicitly refused to provide one ("not a priority" or some such synonym for "we don't care, fuck off"), but I can't find it
In MSFT is forcing Outlook and Teams to open links in Edge and IT admins are angry

Showing the 15 most recent of 33 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.