-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Add stubs for invoke #6938
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
Add stubs for invoke #6938
Conversation
arnimarj
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wrote stubs for the subset of invoke I've been using. Some if them I put in this comment. I'd be happy to send them all over if you like.
| def get_arguments(self): ... | ||
|
|
||
| # TODO use the args | ||
| def task(*args, **kwargs) -> Task: ... |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If it helps here, I've been using this annotation for task:
FuncType = Callable[..., Any]
_F = TypeVar('_F', bound=FuncType)
def task(
func: _F,
*,
name: str = ...,
) -> _F:
...There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
TBH, not sure about this, since it returns a Task object which is not present
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haven't looked at this, but this sounds like a use case for ParamSpec from PEP 612.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I looked at the implementation in a bit more details (https://github.com/pyinvoke/invoke/blob/master/invoke/tasks.py)
The return object is indeed a Task, but the returned type can be controlled via the klass kwarg (currently defaults to Task). The Task object itself implements a __call__ which ends up calling the wrapped method using the given args/kwargs.
My proposed tweak is accurate for the use-cases I have (naked @task wrapping), but the return type is still not accurate.
Co-authored-by: Árni Már Jónsson <[email protected]>
Co-authored-by: Árni Már Jónsson <[email protected]>
Co-authored-by: Árni Már Jónsson <[email protected]>
Co-authored-by: Árni Már Jónsson <[email protected]>
Co-authored-by: Árni Már Jónsson <[email protected]>
Co-authored-by: Árni Már Jónsson <[email protected]>
Co-authored-by: Árni Már Jónsson <[email protected]>
Sure, if it's fine for you I would keep this as a first draft. After the merge you can open a new PR and just merge your hints. Feel free to add me for a short review! |
JelleZijlstra
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks! Looked over all the stubs, and added some suggestions for obvious types that stubgen didn't catch.
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
Co-authored-by: Jelle Zijlstra <[email protected]>
|
Thank you! |
No description provided.