Option to show expanded type instead of type alias on hover

[vishwa-raj]

Can we have an option to show the expanded types instead of the type alias on hover ?

If one uses type aliases to shorten and reuse type hint definitions and there are nested type alias definitions across files, then it becomes very difficult to track down the actual type values.

[judej]

This is similar to #562. Will look at adding a toggle depending on upvotes

[jakebailey]

See my comment here: #562 (comment)

This current behavior is pretty deliberate.

[vishwa-raj]

@jakebailey Yes, I did realize that this behavior is deliberate after going through other related issues (though missed 562).
Hence I requested to make it optional instead of a complete change.

@judej Thanks. Waiting for sufficient upvotes then on 562.

[jakebailey]

This issue (that you opened) would be the place to vote; #562 actually turned out to reveal a bug and has since been fixed.

[vishwa-raj]

@jakebailey Ah, thanks for clarifying.

[vishwa-raj]

@jakebailey I just realised that type aliases do expand on hover or in suggestions when they are part of a Union.
If only there was an option to expand them otherwise as well 🙂

[jakebailey]

They expand because Unions are normalized and type alias names get lost.

TypeScript recently changed this behavior themselves (as they used to do what we do), but we had been pondering adopting their method to preserve type names as much as possible (which is probably the opposite direction you were hoping for).

[vishwa-raj]

@jakebailey Think about it this way:

A type alias allows us to define a large and complex type annotation once and use it multiple times throughout our code, helping to keep it concise and clear.

Now say I import the function func, in the above screenshot, in a file and try to call it by providing the arguments.
The tooltip, like in the second screenshot, will show me ANIMAL_T instead of the actual values, and to know the actual values I'll have to navigate to the source file and check the definition for ANIMAL_T.
And if I have to navigate to the source file to get that info, what's the point of having the suggestion tooltips in the first place ?

[vishwa-raj]

In PyCharm too we get the expanded view in tooltips.

[macintacos]

To share my experience with this, I find it to be a little abrasive from a "developer experience" point of view to need to go-to-def on a type alias that I created more-so to save me from typing out a complicated type, not to "hide" the type.

Granted, at some point one must realize that you're probably just abusing the type system and should refactor 😅 but occasionally I stop myself from creating an alias simply so that I can still see the type information at a glance (or, at-least easier than doing a go-to-def on the alias itself). I'd really appreciate the ability to just see the whole type when hovering, or perhaps show the alias and the type it expands to side-by-side when I hover on a variable that uses the alias. The current implementation seems to actively want to discourage type aliasing because of the reasons previously stated (and the reasons other folks have mentioned in this thread).

All of this to just say - I'd really like for this to be implemented 🙂

[erictraut]

Type aliases are a way to manage and hide complexity. A good alias name should reflect its usage. Can you share an example of a type alias that you've defined where its meaning is not clear from its name?

If you hover over a type alias name (e.g. within a type annotation), pylance will expand it to show you its definition. In other contexts, the type alias name will stand in for the full type that it represents.

We put a lot of effort into retaining and displaying the type alias name because we received feedback from many users that they were overwhelmed by the complexity of the full type, especially when large unions were involved.

I'll note that the current hover behavior in pylance is consistent with the behavior of other language servers like TypeScript and C#.

[macintacos]

Yep, understood that you can hover over the alias name itself in the annotation, but if you're dealing with a variable that's getting passed around, you'll have to go to the variable's definition and then hover over the alias definition - an extra step.

This is definitely a minor inconvenience for sure, and I agree that aliases themselves should have better naming schemes so that their names make their usage obvious. However, sometimes I've been dealing with code where someone has gotten a bit overzealous with how much heavy lifting the alias is actually doing (where the alias is a nested dict type def that can get quite nasty) and it's not really practical in the short term to break it out into "good" aliases, and in those situations being able to see the full complex type you're dealing with is helpful.

I can definitely understand how the complexity of a full type can overwhelm and distract users, hence why I also agree with the premise of this feature request which is to make this an option that users like myself could enable. I for one would appreciate if I could see the alias with it's definition in-line when I hover over a variable that uses that alias.

[bland328]

I can definitely understand how the complexity of a full type can overwhelm and distract users, hence why I also agree with the premise of this feature request which is to make this an option that users like myself could enable.

Agreed strongly. It seems to me there are (at least) two primary motivations for aliasing types:

1. A desire to "abstract away" a complex and frequently-used type, in which case a user might reasonably be annoyed/distracted by the full definition continuing to appear ("I created that alias for a reason, dammit!").
2. A desire to save the all the typing and/or screen real estate of a complex type definition that may be infrequently used, in which case best naming practices may well not be a reasonable substitute for a peek at the definition. ("Uh…how does thing work again?")

On top of that, there are some users who spend all day living inside a single code base with which they are intimately familiar, some users who poke around inside code bases they've never seen before, and some "low-volume" users who infrequently revisit code they once knew intimately.

With all that in mind, I'd argue that for a given user and/or situation, less might be more, or more might be more.

No software can reasonably be expected to be everything to everyone at all times, but given that VS Code is largely a software development tool, I humbly suggest that if it is going to "err on the side" of something, it should err on the side of showing the user more than they wish to see, rather than on the side of abstracting too much away.

[judej]

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

[Tinche]

Apologies for slightly necro-posting here. I'm adding some type aliases to the cattrs library so this is fresh on my mind now.

Instead of having to pick between the alias and the expanded type, is there a universe where we can get both?

The following screenshot shows an autocompletion tooltip with the current argument as StructureHook.

But it'd be awesome to also show this expands to a Callable. Maybe an additional line below it, using a more subtle style to keep focus on the alias, but still provide more information. I'm not a UI designer so I don't know what the exact solution is, but I think that extra information would be very valuable.

[its-darsh]

Updates?

[jdbosser]

Bumping this discussion as well, as I am also interested in seeing updates on this.

[IllyaMoskvin]

I'm very interested in this feature. I have a use-case, anonymized from a live project:

from typing import Literal, TypeAlias

ItemType: TypeAlias = Literal['foo', 'bar']

def _get_cache_prefix(item_type: ItemType) -> str:
    return 'baz' if item_type == 'foo' else 'quux'

This allows the type checker to catch if someone calls e.g. _get_cache_prefix('foobar') in the code. But because ItemType is not expanded, there is no "reminder" for the developer of what valid values the argument actually expects.

(Imagine there are many functions that use ItemType to annotate parameters for the full effect.)

[Jemtaly]

@erictraut

Currently, when hovering over a variable, Pylance shows the type alias name (e.g., MyType) rather than the expanded type. I understand this is by design. However, when I right-click and select "Go to Type Definition", it jumps to the underlying type's definition (e.g., the builtin tuple) instead of the type alias definition. Which makes it hard to trace back to the alias itself, and this is quite frustrating when a type alias is used to encapsulate complex generic types.

This feels inconsistent: if the hover intentionally shows the alias name to preserve abstraction, then "Go to Type Definition" should navigate to where that alias is defined, not to the underlying type.

For example:

MyType: TypeAlias = tuple[int, list[int] | None]

# ... elsewhere in the code ...
for data in some_data_source:
    ...

When I am reading the code and want to understand what data is, I try the following:

1. Hover: Shows data: MyType. This hides the structure, so I don't know it's a tuple or what's inside it.
2. Go to Definition (F12) on data: Jumps to the line for data in some_data_source:, which is not helpful.
3. Go to Type Definition: This is the critical failure point. It resolves the alias to its underlying type. Since MyType is a tuple, Pylance jumps straight to builtins.pyi -> class tuple.

If expanding the type on hover isn't planned, could the "Go to Type Definition" behavior at least be updated to respect the type alias?

[erictraut]

@Jemtaly, you're welcome to make that suggestion to the Pylance team. Here's a link to the pylance Github project.