-
-
Notifications
You must be signed in to change notification settings - Fork 344
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
Replace public usages of functools.wraps
#2796
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2796 +/- ##
=======================================
Coverage 99.13% 99.13%
=======================================
Files 115 115
Lines 17206 17207 +1
Branches 3082 3082
=======================================
+ Hits 17057 17058 +1
Misses 104 104
Partials 45 45
|
Huh the typing impact is kinda shocking? |
whoa, great you took the initiative to do this! I didn't know |
oh, so there was no problem and it was just a matter of your first stab at |
Eh, it's more about what you think the intention of wraps is: my first stab pretended wrapped functions are the thing they wrap. My second stab didn't do so. |
Yeah unfortunately the stubs break the wrapped function's signature. This comment explains the situation well: python/mypy#5107 (comment) |
thank you! It broke my brain a little bit, but I now I get the distinction. |
no wait, I'm confused again. I think I'm getting different behavior (in pyright) if not renaming the import to |
Just checked, MyPy doesn't have a plugin for |
oh derp, the repro is #2775 (comment) But replacing |
Just quick comment: I don't think it's worthwhile having both in CI as they have many intentional discrepancies. The only benefit we would have is that our public API would be guaranteed to work... which is probably something we can guarantee another way? (Just typecheck a subset of tests? Type tests that work in both mypy and pyright? Something like that) |
yeah agreed, we'd probably want to strip one of them down a lot. But I've been running both in flake8-trio without too many problems, though that project is definitely doing a lot fewer complex things type-wise - and started with pyright. |
Trying out pyright locally, I cannot reproduce |
I don't know what I did last time, but I made sure to do everything properly now ... and you are indeed right! Sorry for the confusion We should totally add a test for this though, and even if properly setting up pyright is a bigger task - we could for the moment create a dedicated test file with the contents of #2775 (comment), and for the moment run pyright only on that file in check.sh and/or pre-commit. Maybe a directory |
Well, that's probably not the implementation you wanted but I went ahead and added a regression test @jakkdl |
With |
lol yeah, I'm not a fan of tests with code in strings. Teamspen210's idea is the same as mine. |
Well hopefully that works, I should learn my lesson at this point about not using the web editor ever... It's just too tempting :( |
@@ -72,7 +72,7 @@ | |||
DEADLINE_HEAP_MIN_PRUNE_THRESHOLD: Final = 1000 | |||
|
|||
# Passed as a sentinel | |||
_NO_SEND: Final = cast("Outcome[Any]", object()) | |||
_NO_SEND: Final["Outcome[Any]"] = cast("Outcome[Any]", object()) |
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.
This should probably be reported as an issue but gehhhhh
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 think this makes sense, looks good to me.
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.
Other than small question about check.sh
this looks great!
I'm going to merge this. Pypy 3.9 nightly failing on Windows happens elsewhere and this way we can ask for more testing of the types! I think any further changes can be done in a new PR. |
I'm not entirely sure this works right but I can try figuring out how to configure pyright in a day or something unless someone else wants to check!
Unfortunately yet another pyright incompatibility -- while we could just replace usages around methods this is probably easier?