Upgrade dmypy to a language server (LSP)

[lithammer]

Feature

I would like for dmypy to be a fully fledged language server. Obviously it would only support diagnostics (which would make this much simpler). But this would be very convenient from an editor point on view given the direction editor tooling is going.

Could probably use something like https://github.com/openlawlibrary/pygls to handle the low level details of LSP.

Pitch

Most editors and their plugins shell out and call mypy. But this can be quite slow on some projects since it needs to cold start every time (except for .mypy_cache).

[sileht]

I made a prototype to see what is missing: https://github.com/sileht/dmypy-ls

[jjlee]

Could this support exposing the types of variables, or would that be a different issue? I don't recall the name of the LSP feature, but I want to be able to ask my editor (emacs) what the type of a variable is. This is the "same" feature which in many editors shows the type in a tooltip when you hover the mouse over a variable, or maybe when you leave your cursor there for a while (VS code implements this feature using proprietary code I believe, though I'm not sure whether the types it shows are strictly mypy types).

Currently if I want to do that I have to use reveal_type(), which is very tedious, and so I have much less direct awareness of what mypy thinks types are than I'd like.

Seeing types of things other than variables would be even nicer (something like: return values, expressions, parts of expressions), but variables would be a big step forwards.

[StrictlyMonad]

Anyone that has been working on this PR since last year?

[DanCardin]

#12168 Newer issue for the same thing, just for linking's sake.

---

I dont know whether the dmypy server is the way it is for any particular reason, maybe someone more familiar with its inception could comment. It seems like given an LSP implementation, you could just as easily produce a dmypy cli that queried the LSP rather than the more manual approach currently being taken to implement the server.

Actually authoring an LSP server seems to be trivially easy:

from pygls.server import LanguageServer
from lsprotocol.types import TEXT_DOCUMENT_INLAY_HINT, InlayHint, InlayHintKind, InlayHintParams, Position

server = LanguageServer("example", "v0.1")

@server.feature(TEXT_DOCUMENT_INLAY_HINT)
def inlay_hints(_: InlayHintParams) -> list[InlayHint]:
    return [InlayHint(Position(1, 1), label="int", kind=InlayHintKind.Type)]

server.start_io()

To that end, I prototyped a mypy-based LSP to provide inlay-hints (https://gist.github.com/DanCardin/5026d42d57f33c051e454eb9d58efa5d).

It basically led me to believe that this is realistically only feasible if mypy implements it, versus some third party package. Either that, or a lot of the code in dmypy would need to be revised in a way that made it possible to avoid copy-pasting large swathes of it in order to change small sections.

But my point here mostly being, it naively seems like supporting an LSP server (using i.e. pygls) would represent a net reduction in maintenance burden versus dmypy's manually implemented server, while also being more generally useful to editors

[JukkaL]

I am open to having an LSP server implementation included in mypy (eventually), but to completely replace dmypy we need to support all the existing functionality, or at least provide reasonable alternatives. Perhaps this won't be a problem, but I have no idea if some features would be hard to support. I agree that having one server implementation would be desirable and could simplify maintenance.