-
Notifications
You must be signed in to change notification settings - Fork 52
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
Comments
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. |
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 @unsync
def test_dict() -> Unfuture[dict]:
# noinspection PyTypeChecker
return {'x': 1}
def use_dict():
_dict = test_dict().result()
_dict.get('x') |
My message above however does have two issues.
|
The way I solve this problem is an assert isinstance after the call that returns unfuture. Not ideal either, but grants me full inspection. |
I think this library cannot target Python < 3.5 anyway because it uses the |
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 theUnfuture
would be generic such that we know which value.result()
returns.The text was updated successfully, but these errors were encountered: