Add type stub for decorator lib#3038
Conversation
|
Thank you for your pull request. Could you break out the change to |
|
Yes, splitting the the PR in two parts will definitely simplify the sync. |
srittau
left a comment
There was a problem hiding this comment.
I already mentioned splitting out the changes to contextlib. I left further remarks below.
ccd30a9 to
e3e10cd
Compare
66e8489 to
5b44391
Compare
|
I split the contextlib changes out into #3083 |
|
OK, all tests now pass here. |
|
@srittau could you review this again? |
|
bump, can someone look at this again please? :) |
|
Sorry for missing this. I will look at it tomorrow. |
srittau
left a comment
There was a problem hiding this comment.
Sorry again for forgetting about this. This is a full re-review, so I might remark on things that I have remarked on before.
pull via github
7f28422 to
9f96b73
Compare
9f96b73 to
8fcc03f
Compare
|
For future reference: please don't force push, otherwise it is hard for reviewers to see what has changed since the last review. |
I emailed the repo owner directly and got permission to add this stub; here's a public issue for visibility/posterity micheles/decorator#69
I tested some of this behaviour locally; I'll be adding a mypy test in a separate pull request to the mypy repo.
For the purpose of code-review, here's a test I used:
running the test generates
running mypy generates
Line 23 demonstrates that the type annotation of
greetis correct after decoration with@print_before; trying to pass1asTextcauses a type error.Similarly, to give more confidence, lines 38-43 show that
decoratedmatches the type signature offso thatmemoizefulfills its contract of(F) -> F; resulting ingreetandmemoize(greet)having the same type.Depends on #3083