Open PeterJCLaw opened 8 months ago
I agree, this should probably be easy!
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 :shrug:
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:
TypeAlias
when we get into working out its symbol in typing
and perhaps return a custom type theretree_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:
typing
(i.e: other _SpecialForm
s, 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 hereThese 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).
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.
Currently types annotated as being
TypeAlias
end up not having any useful members. Probably the simplest fix is to ignore the annotation when it'styping.TypeAlias
since manually removing the annotation does normally bring completions back.