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

Improve type inference for recursive protocols #3829

Open
ilevkivskyi opened this issue Aug 15, 2017 · 1 comment
Open

Improve type inference for recursive protocols #3829

ilevkivskyi opened this issue Aug 15, 2017 · 1 comment

Comments

@ilevkivskyi
Copy link
Member

Consider this example:

class P(Protocol[T_co]):
    def meth(self) -> P[T_co]: ...

class C(Generic[T]):
    def meth(self) -> C[T]: ...

def fun(arg: P[T]) -> T: ...
x: C[int]
reveal_type(f(x))  # I think this should be 'int'

But currently the inferred type is UninhabitedType, since we don't find any constraints for T due to a purely structural inference cycle. Unfortunately, it looks like this doesn't have simple solutions.

This is a follow-up for #3132

@ilevkivskyi
Copy link
Member Author

Here is a possible idea how this can be implemented (semi-heuristically):

  • We would record a pair of Instances that we tried to match instead of just the template's TypeInfo like now.
  • Then if we hit the same pair (using is_same_type), instead of just "backtracking" (like now, we simple say no luck here, try another options) we can try "forceful unpacking". For example if we started from C[int] <: P[T] we continue with int <: T (which is a leaf in this simple case).
  • Ideally this should be done with something like map_instance_to_supertype, but the essence of the problem is that there is no such thing for structural subtypes, however it seems to me the fact that we recursed to the same pair of Instances already tells that the types can be "mapped".
  • Obviously we should do this only if the instance matches the protocol with typevars erased. Also we should probably do some variance checks to avoid problems.
  • I don't have a proof but we can call this heuristics :-)
  • We need to think is there a possibility for any "fake" constraints because of this.

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

No branches or pull requests

3 participants