Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for TypeAlias #1969

Open
PeterJCLaw opened this issue Nov 6, 2023 · 4 comments
Open

Add support for TypeAlias #1969

PeterJCLaw opened this issue Nov 6, 2023 · 4 comments

Comments

@PeterJCLaw
Copy link
Collaborator

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
Copy link
Owner

I agree, this should probably be easy!

@PeterJCLaw
Copy link
Collaborator Author

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
Copy link
Collaborator Author

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
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants