You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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).
Reacted by bugsbugsbux, Salomon Popp, Thomas M Kehrenberg, Robert, KotlinIsland, DetachHead, 2*yo, Marti Raudsepp, efokschaner, Froger David and 19 more
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.
#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:
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
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.
Reacted by Duncan Holm, Lukas Juhrich, Dmitry Balabka and godalming123
Activity
[-]Level up dmypy to a language server[/-][+]Upgrade up dmypy to a language server (LSP)[/+][-]Upgrade up dmypy to a language server (LSP)[/-][+]Upgrade `dmypy` to a language server (LSP)[/+]sileht commentedon Dec 20, 2021
I made a prototype to see what is missing: https://github.com/sileht/dmypy-ls
jjlee commentedon Mar 7, 2022
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 commentedon Jul 9, 2023
Anyone that has been working on this PR since last year?
DanCardin commentedon Sep 19, 2023
#12168 Newer issue for the same thing, just for linking's sake.
I dont know whether the
dmypyserver 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 admypycli 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:
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
JukkaL commentedon Sep 19, 2023
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.