Open yangdanny97 opened 3 weeks ago
As far as I can tell we don't use the typechecker for inference anywhere else in stub generation. Those results would be dependent on context and I imagine there's a lot of edge cases to handle which would expand the scope of the change significantly.
This PR is much simpler, it's not context-sensitive and is entirely syntax-based. I think I'd prefer investigating ExpressionChecker as a separate/future issue, since it seems like a much bigger task.
I'd prefer if we used ExpressionChecker. Having a second visitor that does some subset of expression inference is just confusing and is a maintenance burden (since it will accrete functionality that already exists and is well trodden). I'm not sure what you mean by context sensitive here / I'm not sure that that's a bad thing. If you're concerned about inference. results, I'd be happy with a PR that used ExpressionChecker but made use of inference optional via flag / filtered out complex types (e.g. just filtered to non-builtins.object Instance
or two element UnionType
with None)
This PR extends stubgen to guess return types for some functions based on the returned expression. This is inspired by autotyping's
scalar-return
flag, with the addition of being able to handle literal lists, tuples, sets, and dicts.There are some limitations:
This only works on concrete functions at least one return statement & no yield/yieldfroms. It only works on literals, tuples of literals, or homogeneous container literals. Additionally, it only works if all the return statements return the same type or
None
.To verify this behavior, I added a test case with some examples and updated all the existing stubtest cases.