Per Guido Van Rossum's suggestion, I am re-posting what was initially opened as an issue at python/typing (https://github.com/python/typing/issues/727). I am unsure if this issue should go here or rather to mypy's tracker. I have looked through issues in both `typing` and `mypy` and couldn't find anything related. Consider the following code: ```py import typing as tp class A: x: int def f1() -> A: return A() def f2() -> tp.Any: return f1() x = f1() x.x = "" # [1] y = f2() y.x = "" # [2] ``` Upon checking with mypy, an expected `Incompatible types in assignment (expression has type "str", variable has type "int")` error is emited at [1], but not at [2]. This makes sense, as type of `y` is `Any`. However, e.g. [jedi](https://jedi.readthedocs.io/en/latest/) autocompletion library is smart enough to deduce that `f2() -> A`. While in the above degenerate example it would be trivial to just property annotate the `f2`, the real scenario has `A` and `f1` defined in some library, and `f2`, which does something more useful than just calling `f1` is defined in user-code. Specific class `A` is not intended to be directly instantiated by the user, moreover, it may be buried deeply inside module hierarchy, which may also change between library releases. My suggestion is to introduce `typing.Auto` which, when used in return type annotation, would instruct type checker (mypy or any other) to infer return type from the type of expression in return statement. In case of multiple return statements, the pragmatical approach would probably be to infer the base-most class, possibly issuing an error or a warning if types are completely unrelated. Another possibility is to optionally have mypy treat `typing.Any` return types in a manner suggested for the above-described `typing.Auto` but I suspect that this would be a breaking change. P.S. `typing.Auto` should also be usable within `typing.Tuple`. I am not sure whether it would be desirable to allow inference of tuple in cases when return type is annotated as `typing.Auto`.