Skip to content
This repository has been archived by the owner on Apr 14, 2022. It is now read-only.

Announcing Pylance: Fast, feature-rich language support for Python in Visual Studio Code #2096

Open
huguesv opened this issue Jun 30, 2020 · 10 comments

Comments

@huguesv
Copy link
Contributor

huguesv commented Jun 30, 2020

We are excited to announce Pylance, our fast and feature-rich language support for Python! Pylance is available today in the Visual Studio Code marketplace.

Please see the announcement for more details: https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/

If you are currently using VS Code with the Microsoft language server, we encourage you to give Pylance a try!

Please note that Pylance bugs should be filed at https://github.com/microsoft/pylance-release/issues

Thanks!

@huguesv huguesv pinned this issue Jun 30, 2020
@ghost
Copy link

ghost commented Jul 1, 2020

after installing pylance, and setting it as default language server, I get this problem in my setting.json,
Value is not accepted. Valid values: "Jedi", "Microsoft", "None".(1)

my code version is:
1.46.1
cd9ea6488829f560dc949a8b2fb789f3cdc05f5d
x64

@huguesv
Copy link
Contributor Author

huguesv commented Jul 1, 2020

@jaguarest please see microsoft/pylance-release#16

@d0mf1g
Copy link

d0mf1g commented Jul 3, 2020

So I take it that this repo will eventually be deprecated as work moves to improving Pylance?

@CatNofishing
Copy link

Awesome! Great Job! 😁

@Seirdy
Copy link

Seirdy commented Jul 25, 2020

@huguesv will the MPLS (this repository) continue to be maintained in the future?

I ask because I use language servers with Neovim's built-in LSP client implementation, not VSCode. It looks like Pylance won't be open-sourced, which will make building/packaging/running it difficult on many platforms. If that is the case, many users of MPLS who use LSP clients besides VSCode will have to migrate over to palantir/python-language-server (slow), muffinmad/anakin-language-server, or pappasam/jedi-language-server (limited functionality, but can be combined with diagnostic-langserver for diagnostics and formatting).

@savannahostrowski
Copy link

savannahostrowski commented Jul 30, 2020

Hey @Seirdy

Our team's plan is to transition users in VS Code over to Pylance. After that, this repository will no longer be maintained, at which point you would have to migrate over to another open-source option. Depending on your use case, you might also be interested in checking out Pyright (which powers the Pylance language server) or forking this repo.

@noelevans
Copy link

What an amazing decision. The idea of LSPs was created by Microsoft. I've watched YouTube videos of Microsoft employees lauding their achievements in this space. MPLS was the clear winner for Python against the existing options. What a lame outcome.

@Seirdy
Copy link

Seirdy commented Jul 30, 2020

Depending on your use case, you might also be interested in checking out Pyright
(which powers the Pylance language server) or forking this repo.

Thanks for the heads-up, @savannahostrowski

Having some documentation on using Pyright as an editor-agnostic language server and/or seeing more support in other LSP clients (cf neovim/nvim-lsp#303) to aid in migration before this repository is archived would be appreciated.

@Kurtoid
Copy link

Kurtoid commented Aug 10, 2020

I'm not a fan of migrating from an Open Source solution to a closed-source one. It's nice that Pyright is OSS, but I'm skeptical of Pylance

@DoS007
Copy link

DoS007 commented Apr 11, 2021

Hmm, that sounds a bit like microsoft's old strategy: https://en.wikipedia.org/wiki/Embrace,_extend,_and_extinguish .

I think Microsoft's whole purpose with creating vscode and especially the "language server protocol"(LSP) is to apply their "embrace, extend, extinguish" strategy on code editors. They created a cool code editor with a cool concept called LSP. The editor quickly becomes the most popular editor in the world since its "open source". Most other editors shift to using LSP coz it becomes a standard for editor-agnostic code diagnostics. This is the "embrace" part.

Microsoft slowly breaking their own protocol (I have seen a few blog posts of LSP-client developers complaining about vscode breaking its own protocol and that language-servers tend to follow vscode and not the LSP standard). This is the extend part.

Microsoft, if successful, might try to extinguish all open source editors by breaking LSP more and more, making the development process of competing editors harder and harder since they completely rely on LSP for diagnostics. on the meantime, they might make vscode more and more closed source (and start by making its extensions more and more closed). This is the extinguish part.

Source

Hopefully this won't happen.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants