Python at Microsoft

> Pyright was released first and was and continues to be open source. Pylance was built on Pyright but has never been open source.

No, the first Python extension that shipped with vscode 1.0 in 2016 was called the "Microsoft Python Language Server" and was based on the Jedi LSP. Below is the deprecation announcement of the Jedi language server in the Pylance launch post below.

> In the short-term, you will still be able to use the Microsoft Python Language Server as your choice of language server when writing Python in Visual Studio Code. > Our long-term plan is to transition our Microsoft Python Language Server users over to Pylance and eventually deprecate and remove the old language server as a supported option. https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/#the-future-of-the-microsoft-python-language-server

> But they are probably worried about Windsurf and Cursor, the latter of which (a billion-dollar company) was caught violating MS's TOS around the plugin ecosystem.

If that were so, I would certainly understand. However, MS started closing vscode and the extensions years before Windsurf and Cursor (initial release in 2023). This was their business model all along get adoption in partly by leveraging the open source community, and then close things off slowly once they have a choke hold (similar to Android/AOSP). I could scarcely agree more that Windserf and Cursor are supremely sketchy…

> Having a half way decent type system solves so many problems

What problems does it solve for you? When building ML applications I mean. Because that's what S4TF was supposed to be.

ML researchers produce models that are used by ML applications for a particular purpose. The code to train the model _could_ be statically typed, sure, but I really don't see what the improvement would be. It would be more verbose, less readable, have significantly more noise. Just try reading some TensorFlow C++ code equivalents of their Python API.

From the "WhySwiftForTensorFlow.md" document (https://github.com/tensorflow/swift/blob/main/docs/WhySwiftForTensorFlow.md#static-vs-dynamic-type-systems):

.. static types:
* can catch bugs at compile time instead of runtime. People get very frustrated when a silly type error brings down a long training run hours into it.
* directly improve tooling experience like code completion/intellisense, jump to definition, etc.
* make it easy to know what operations are Tensor operations.

> can catch bugs at compile time instead of runtime.

OK, but what bugs? For most use cases of TensorFlow that I've seen, if there is a type error somewhere, you will catch it long before it hits production, and if you only catch it 100hr into training, your training code is either non-deterministic or there's some other issue that is not type related. Unless we're talking about dependent types a-la Idris, I don't see how Swift's type system can help catch these kinds of…

>> All things considered, it's well past time to stop being so harsh on Redmond. Stop judging Microsoft on what it did a decade ago and judge it by what it's doing today.

You mean like closed sourcing previously open source VS Code extensions?

They recently announced that they are closed sourcing the C# VS Code extension:

"Once the “LSP Tools Host” is complete, this will become the default experience for the C# for VS Code extension. Existing users will be able to choose between the open-source OmniSharp powered system that exists today, or the new “'LSP Tools Host” which will provide access to additional experiences. The “LSP Tools Host” will not be open-sourced, but we plan to communicate with the community along the way to help guide our future plans."[1]

The same thing was done with PyLance which was "extended" from PyRight.[2]

Why would they do this?

Because VS Code can't get good enough to compete with Visual Studio. If it did, they would lose revenue by not selling enough copies of Visual Studio.

It's the same Microsoft, they've just had to adapt since they lost a lot of the power they had in the past.

[1] https://github.com/omnisharp/omnisharp-vscode/issues/5276

[2] https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/

It's important to understand that the type systems for Python are not really an inherent feature of Python, but the systems enforced by each of the static checkers (which tend to adopt each other's advancements and drive syntactic support into the core system of annotations, so there's a common baseline advancing with the individual systems). A recent advancement in one of those type systems would be pylance (actually pyright, since that's the typechecker for the pylance language server) support for higher-kinded type variables [0]. Mypy, I believe, has identified this as a thing to support, too.

An example of an improvement in annotations specifically to enable type system improvements that require supporting syntax improvement is PEP 646 support for Variadic Generics. [1] Even though it is in draft, pyright has already landed support for it for the type system improvements motivating it. [2]

[0] item #4, https://devblogs.microsoft.com/python/pylance-introduces-five-new-features-that-enable-type-magic-for-python-developers/

[1] https://www.python.org/dev/peps/pep-0646/

[2] https://github.com/microsoft/pyright/releases/tag/1.1.107

This covers it very well: https://devblogs.microsoft.com/python/idiomatic-python-eafp-versus-lbyl/

In particular, this is not idiomatic python:

if "key" in dict_:
value += dict_["key"]

But this is:

try:
value += dict_["key"]
except KeyError:
pass

I too hate using the exception handling in this way, and if you aren't careful, you end up papering over other unexpected exceptions in your code, so you have to be (A) very specific in the exception you catch, and (B) keep it in as small a portion of code as possible.

I just think it makes for clumsy code - which of the two look better:

try:
value = dict_["key"]
except KeyError:
pass
else:
do_something(value)

OR

if "key" in dict_:
do_something(dict["key"])

But it might just be me.

This title is inaccurate.

The language server _is_ open source, and is available here: https://github.com/microsoft/python-language-server. This is the default one VSCode ships with.

This issue is filed on Pylance, a new (released June 2020) language server that's currently still in beta (announcement: https://devblogs.microsoft.com/python/announcing-pylance-fast-feature-rich-language-support-for-python-in-visual-studio-code/).

Also, like the contributor notes, a lot of the "secret sauce" in Pylance is part of the open source Pyright typechecker: https://github.com/microsoft/pyright.