Skip to content

"auto" return type #727

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

Closed
kshpytsya opened this issue May 26, 2020 · 4 comments
Closed

"auto" return type #727

kshpytsya opened this issue May 26, 2020 · 4 comments
Labels
resolution: duplicate The idea/problem was already reported topic: feature Discussions about new features for Python's type annotations

Comments

@kshpytsya
Copy link

kshpytsya commented May 26, 2020

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:

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 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.

@gvanrossum
Copy link
Member

gvanrossum commented May 26, 2020 via email

@elazarg
Copy link

elazarg commented May 26, 2020

#276
Also there's a related discussion here: python/mypy#4409

@devdoomari3
Copy link

you can probably use https://github.com/Instagram/MonkeyType to add types, though it's runtime (not static-analysis tool)

@srittau srittau added resolution: duplicate The idea/problem was already reported topic: feature Discussions about new features for Python's type annotations labels Nov 4, 2021
@srittau
Copy link
Collaborator

srittau commented Nov 4, 2021

Closing as a duplicate of #276.

@srittau srittau closed this as completed Nov 4, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
resolution: duplicate The idea/problem was already reported topic: feature Discussions about new features for Python's type annotations
Projects
None yet
Development

No branches or pull requests

5 participants