Option to use qualified names in textDocument/hover

[Gobot1234]

Is your feature request related to a problem? Please describe.
I am currently writing a program to evaluate annotations for my documentation builds so variables that can't be evaluated by sphinx can be cross linked correctly using pyright's LSP and textDocument/hover. Currently evaluating types without a qualifier isn't particularly easy so I'd like to propose an option which prefixes symbols with their module

Describe the solution you'd like
An option to prefix symbols with their module which is disabled by default i.e.
(variable) y: Literal[1] -> (variable) y: typing.Literal[1]

[erictraut]

This isn't a core type checking issue, so I'll transfer it to the pylance-release project for discussion there. We've had requests before to expand type aliases for all types on hover (#2715), but I think this may be the first time we've had a request to use fully-qualified names. This seems like a pretty niche use case, so I don't know if the pylance team will be interested in exposing a new setting specifically for this. It's something we could leave open for discussion to see if there is additional interest from users.

[Gobot1234]

I'm using pyright-langserver for this is this not a pyright feature request?

[erictraut]

The pylance team is responsible for all language server features, even those that are implemented in the pyright code base. Pyright is focused on core type checking features. Any feature request that involves language server changes or settings (which are common to pylance or pyright) need to go through the pylance team.

[judej]

Moving this issue to discussion as an enhancement request for comments and upvotes.

[Gobot1234]

Just as a small demo as to why this is necessary in my case

class Literal: ...

class Test:
    x: int = 1

Hovering over x reveals it to be Literal[1] which when evaluated in the file's namespace will resolve to something completely wrong and I have no way of detecting this.

[erictraut]

Using qualified names in hover text won't provide any different behavior here. The local type is still Literal[1]. It sounds like what you would like is for hover text to include both the local type and the declared type (which, in this case, is int). I think it would be very confusing to most users if we were to display both types, so it's unlikely we'd do that.

[Gobot1234]

If it showed typing.Literal[1] rather than __main__.Literal I could special case to handle where typing isn't in locals and just add it to the imports anyway

[Gobot1234]

Not having this feature might have actually bitten someone in the Python discord server recently.

Adding support for this would allow us to more easily be able to help debug us or the user debug these issues (although I'd be remise to not mention that they never sent the whole error which would have made the issue clearer).