Python-language-server: How does this compare to pyls?

Created on 8 Jul 2019  路  6Comments  路  Source: microsoft/python-language-server

As titled, I am choosing between this python-language-server and the one maintained here: (https://github.com/palantir/python-language-server). I'd love to know the differences between these 2 implementations. Cheers!

question

Most helpful comment

Just from the design point of view:

  • Ours is written in C#, compiled with .NET Core to native code that executes, versus being in Python itself. This has performance implications (GIL, concurrency, etc), as well as distribution/platform support differences.
  • That language server is a slew of different libraries hooked together to provide a single language server (jedi for completion, rope for rename, pylint/flake8 for linting, etc), while we're a single codebase in C# that does all of the above in a single structure. We have our own parser, symbol indexing, and so on. The differences with Jedi its own list (very different decisions and functionality in some cases). I won't say that either approach is better or worse overall, but our language server is for the most part impacted by its history in Visual Studio proper.
  • We try to be close to typing in terms of the way we treat variables; if you say that foo is a str, then that's what it is, and we don't do dataflow analysis (at the moment) to notice that you've reassigned it to int and now everything after should be another type.

The tool that works best for you will depend on a number of things; if you're using the VS Code Python extension with Jedi enabled, you're likely to get about the same functionality as the other language server, though some things are deferred until file save, like syntax checking. You can always see what works or doesn't work in both; if something doesn't work with our language server, please do file an issue!

All 6 comments

According to https://langserver.org/#implementations-server, both have LSP feature parity. Past that, I think you'll have to write your own benchmarks or UX comparison.

Just from the design point of view:

  • Ours is written in C#, compiled with .NET Core to native code that executes, versus being in Python itself. This has performance implications (GIL, concurrency, etc), as well as distribution/platform support differences.
  • That language server is a slew of different libraries hooked together to provide a single language server (jedi for completion, rope for rename, pylint/flake8 for linting, etc), while we're a single codebase in C# that does all of the above in a single structure. We have our own parser, symbol indexing, and so on. The differences with Jedi its own list (very different decisions and functionality in some cases). I won't say that either approach is better or worse overall, but our language server is for the most part impacted by its history in Visual Studio proper.
  • We try to be close to typing in terms of the way we treat variables; if you say that foo is a str, then that's what it is, and we don't do dataflow analysis (at the moment) to notice that you've reassigned it to int and now everything after should be another type.

The tool that works best for you will depend on a number of things; if you're using the VS Code Python extension with Jedi enabled, you're likely to get about the same functionality as the other language server, though some things are deferred until file save, like syntax checking. You can always see what works or doesn't work in both; if something doesn't work with our language server, please do file an issue!

I'm going to close this to keep it off the tracker (as it's not actionable), but feel free to followup if you'd like.

Sure, thanks for the detailed explanation!

compiled with .NET Core to native code that executes

Are the binaries published somewhere? Sublime Text instructions depend on having .NET Core installed.

Or is it the .dll that's native and it's tricky to build a self-contained executable? I'm interested in having something easily distributable for Windows, macOS and Linux.

There is no official build location at the moment, other than the blob storage used to give the VS Code extension its download (which is unstable, and we delete builds from there periodically). C# needs a runtime, so the choices are to either dotnet publish and bundle the runtime (what we do), or have an any-playform single download but require an external dotnet installation (not easy at the moment).

Was this page helpful?
0 / 5 - 0 ratings

Related issues

MichalPospech picture MichalPospech  路  33Comments

DonJayamanne picture DonJayamanne  路  36Comments

kaushall picture kaushall  路  37Comments

brettcannon picture brettcannon  路  29Comments

Salzy picture Salzy  路  31Comments