"auto" return type #727
Labels
resolution: duplicate
The idea/problem was already reported
topic: feature
Discussions about new features for Python's type annotations
I am unsure if this issue should go here or rather to mypy's tracker. I have looked through issues in both
typing
andmypy
and couldn't find anything related.Consider the following code:
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 ofy
isAny
. However, e.g. jedi autocompletion library is smart enough to deduce thatf2() -> A
. While in the above degenerate example it would be trivial to just property annotate thef2
, the real scenario hasA
andf1
defined in some library, andf2
, which does something more useful than just callingf1
is defined in user-code. Specific classA
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-describedtyping.Auto
but I suspect that this would be a breaking change.P.S.
typing.Auto
should also be usable withintyping.Tuple
. I am not sure whether it would be desirable to allow inference of tuple in cases when return type is annotated astyping.Auto
.The text was updated successfully, but these errors were encountered: