-
-
Notifications
You must be signed in to change notification settings - Fork 343
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
isort take 2 #2686
isort take 2 #2686
Conversation
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## master #2686 +/- ##
==========================================
- Coverage 98.84% 98.84% -0.01%
==========================================
Files 113 113
Lines 16488 16474 -14
Branches 3003 3004 +1
==========================================
- Hits 16297 16283 -14
Misses 134 134
Partials 57 57
|
Huh, CI failing seems weird. It doesn't seem to be any sort of environment change but it's hard to imagine import re-ordering affecting static tools like that- actually, it isn't that hard to imagine. I'll guess there's maybe duplicate somethings somewhere...? Or I don't know, maybe just revert certain files and I'm also not too sure about how I feel about such a large diff that will probably lead to a ton of merge conflicts! It's probably fine though since I think most open PRs are dead (as far as I know). |
trio/_tests/test_exports.py
Outdated
if tool == "jedi" and sys.version_info >= (3, 11): | ||
if class_ in ( | ||
trio.DTLSChannel, | ||
trio.MemoryReceiveChannel, | ||
trio.MemorySendChannel, | ||
trio.SSLListener, | ||
trio.SocketListener, | ||
): | ||
missing.remove("__aenter__") | ||
missing.remove("__aexit__") | ||
if class_ in (trio.DTLSChannel, trio.MemoryReceiveChannel): | ||
missing.remove("__aiter__") | ||
missing.remove("__anext__") | ||
# if tool == "jedi" and sys.version_info >= (3, 11): | ||
# if class_ in ( | ||
# trio.DTLSChannel, | ||
# trio.MemoryReceiveChannel, | ||
# trio.MemorySendChannel, | ||
# trio.SSLListener, | ||
# trio.SocketListener, | ||
# ): | ||
# missing.remove("__aenter__") | ||
# missing.remove("__aexit__") | ||
# if class_ in (trio.DTLSChannel, trio.MemoryReceiveChannel): | ||
# missing.remove("__aiter__") | ||
# missing.remove("__anext__") |
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.
the 3.11&3.12 failures are because I accidentally pushed this - I think my local environment updated jedi
or something and these are no longer missing, but I forgot to undo the commenting before pushing in this PR.
Will look at the windows fails
if sys.platform != "win32" or not _t.TYPE_CHECKING: | ||
try: | ||
from socket import ( | ||
sethostname as sethostname, | ||
if_indextoname as if_indextoname, | ||
if_nameindex as if_nameindex, | ||
if_nametoindex as if_nametoindex, | ||
if_indextoname as if_indextoname, | ||
sethostname as sethostname, | ||
) | ||
except ImportError: | ||
pass |
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.
The windows CI fails is because pyright
now doesn't see if_indextoname
, if_nameindex
or if_nametoindex
on windows ... but it sees sethostname
? And why did it "work" in the first place, since sys.platform == "win32"
and _t.TYPE_CHECKING == TRUE
it shouldn't have ever seen these symbols if it's parsing the if
statement.
Regardless, I don't think it's an issue, and I don't care to dig deeper into it atm, so I'll just Remove
those in the test.
They're either dead, or by me 😇 |
The only failing check is an erroneously duplicated |
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.
Passes a spot check. I didn't look too hard but I assume this is all good cause tests pass!
I'm going to see if people on Gitter have Opinions about this but I think this is a good enough change to merge despite merge conflicts it will cause.
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.
Do we need to run isort
after it's regenerated?
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 manually sorted the imports in gen_exports.py
so they pass - though upon reflection I should probably just # isort: skip
as that's how the black formatting is handled, and shoehorning in isort
to work with gen_exports.py --check
or forcing future people to manually sort the imports does not sound fun.
I didn't read the PR or issue, but this is useful for this kind of refactor. |
oooh, this is great. Thanks a lot! |
I don't think you can add the |
I rebased and split the PR among three commits, one to add |
Great! 👍 |
Since nobody's complaining, I'll go ahead and merge 🚀 |
I think the commit is actually 933f77b ? |
oh huh, yep. It's definitely listed as |
#2538 got abandoned, but that felt in large part because it was just a one-off random big reorg. This adds
isort
to CI, and it only needed a singleisort: skip
for it to work for the whole project.