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

Typing #15

Open
Luttik opened this issue Jul 16, 2019 · 5 comments
Open

Typing #15

Luttik opened this issue Jul 16, 2019 · 5 comments

Comments

@Luttik
Copy link
Contributor

Luttik commented Jul 16, 2019

It would be great if the IDE could understand that an unsynced method returns an Unfuture rather than the usual data. And it would be even sweater if the Unfuture would be generic such that we know which value .result() returns.

@alex-sherman
Copy link
Owner

Agreed, that would actually be awesome. I'm looking into how that would be possible and I believe there is currently not support for decorators modifying the return type of their functions within the Python typing specification.

If there are any examples of this being done, I would be more than happy to look further into it, but for the time being I think there is nothing I can do to support this.

@Luttik
Copy link
Contributor Author

Luttik commented Jul 17, 2019

The code in this commit works if you use python 3.5 or high. Makes the issue less severe, since you can then type the response of your method as future manually. This way you only need to disallow type inspection at the point where you return the response of the method. And the IDE knows that .result() is a method of the response of test_dict() and that result() now returns a dict.

@unsync
def test_dict() -> Unfuture[dict]:
    # noinspection PyTypeChecker
    return {'x': 1}


def use_dict():
    _dict = test_dict().result()
    _dict.get('x')

@Luttik
Copy link
Contributor Author

Luttik commented Jul 17, 2019

My message above however does have two issues.

  1. You still have to use a noinspect somewhere.
  2. It will not work for python < 3.5 (I guess there are options to fix this but I never build stuff for python < 3.7 so I don't have experience in this area)

@EliseAv
Copy link

EliseAv commented Jul 17, 2019

The way I solve this problem is an assert isinstance after the call that returns unfuture. Not ideal either, but grants me full inspection.

@alex-sherman
Copy link
Owner

I think this library cannot target Python < 3.5 anyway because it uses the async keyword, so I'm OK with including things that require >=3.5. @Luttik I actually really like the idea of supporting typing inside Unfuture at, if you open a pull request with that commit I'm happy to accept it unless you think there is some reason not to include that. It doesn't fully solve the problem but at least it's a step in the right direction.

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

No branches or pull requests

3 participants