Add support for TypeAlias

[PeterJCLaw]

Currently types annotated as being TypeAlias end up not having any useful members. Probably the simplest fix is to ignore the annotation when it's typing.TypeAlias since manually removing the annotation does normally bring completions back.

[davidhalter]

I agree, this should probably be easy!

[PeterJCLaw]

Aside: I've since spotted that in Python 3.12, the type statement results in the deprecation of TypeAlias as an annotation. Not sure I really like that syntax either, but 🤷

[PeterJCLaw]

Stepping through this the important bit is, I think, where we end up in tree_name_to_values and fall through the annassign branch within the loop for name in names. This ends up computing the ValueSet over the annotation, however in this case that's not really useful.

I'm not really sure what the idea change is though. We do need to run at least some of the infer... logic on the annotation in order to know that it's typing.TypeAlias (we could do some name hackery, but that doesn't feel like it's the right solution), however the results we get from infer_annotation(...).execute_annotation() aren't really what we want. I think there might be a world where we do the infer_annotation(...) part but not the execute_annotation() part, however even that seems to go a bit too far -- we're into typing._SpecialForm at that point, where I think we need an explicit marker that we're dealing with TypeAlias.

I think one option here is to:

• Somehow intercept the processing of TypeAlias when we get into working out its symbol in typing and perhaps return a custom type there
• That type can then either be checked for in tree_name_to_values (by instance/property/whatever) such that we can know that we don't want to use the annotation and should look onwards at the assignment. For TypeAlias specifically we might even want to jump directly to processing the assigned value as a type, but I'm not sure that's entirely useful to add given that simply removing the : TypeAlias part from the source seems to work fine even if the assigned value is a string.

The alternative I can think of here is perhaps more general, though potentially has other impacts. In theory I think we could opt to always evaluate the assigned value in the case where the type annotation doesn't resolve to anything useful. Exactly what "not useful" means here is debatable, but I'm mostly thinking of:

• stuff which isn't a type
• things which looks like types, but resolve to empty values (e.g: missing import)
• maybe some odd cases in typing (i.e: other _SpecialForms, which are likely to result in an empty ValueSet after ``execute_annotation()`); this last one is the case I'm worried might have weird consequences here

These two things aren't exclusive either -- we could have both if we wanted.

I'm leaning more towards the first option -- it feels like a better solution to the specific problem here.

Would be good to get your thoughts and perhaps some pointers towards intercepting the processing of TypeAlias into a custom node (if that's a sensible approach/I'm thinking about that right).

[davidhalter]

Sorry for the large delay, I kind of forgot about this tab and got sick after. I'm generally fine with both options. I think both options are better then the status quo.

The reason why I don't think Option 2 is terrible is that Jedi has never been about absolute precision like Mypy for example, we have always tried to give the user as much as possible, even with sometimes questionable heuristics. This might be another "questionable" heuristic, that is however not completely wrong either when it comes to autocompletion.