镜像站点 · 本页由第三方 GitHub 只读镜像提供,非 GitHub 官方站点,不接受任何登录或凭据输入。前往 github.com
Skip to content

Upgrade dmypy to a language server (LSP) #10463

Open

Description

@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).

Activity

  1. changed the title [-]Level up dmypy to a language server[/-] [+]Upgrade up dmypy to a language server (LSP)[/+] on Oct 28, 2021
  2. changed the title [-]Upgrade up dmypy to a language server (LSP)[/-] [+]Upgrade `dmypy` to a language server (LSP)[/+] on Oct 28, 2021
  3. sileht commented on Dec 20, 2021

    @sileht
    Contributor

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

  4. jjlee commented on Mar 7, 2022

    @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.

  5. StrictlyMonad commented on Jul 9, 2023

    @StrictlyMonad

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

  6. DanCardin commented on Sep 19, 2023

    @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://github.com/proxy/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

  7. JukkaL commented on Sep 19, 2023

    @JukkaL
    Collaborator

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions