STYLE, TYP Turn black formatter off for overloads #40973
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This comment has been minimized.
This comment has been minimized.
|
looks like |
any objections to removing |
| ... | ||
|
|
||
|
|
||
| def take_nd(arr: np.ndarray, indexer, axis: int = ..., fill_value=..., allow_fill: bool = ...) -> np.ndarray: ... # noqa | ||
| @overload |
There was a problem hiding this comment.
can the noqa be made specific, i think # noqa:F501,E704
|
I think I prefer the status quo |
|
Sure, let's stick to that then 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Following on from the monthly meeting's discussion, some things were suggested:
.pyfiles (what I've done here).pyifiles, writing a script to keep them in sync (I tried that this, and it seems thatmypybehaves a bit differently with a.pyifile than it does with a.pyfile - will look into this more closely, but it'll take more time).pyfiles and "injecting" them before runningmypyvia a script - IMO this might be slightly disruptive to the usual workflow of just runningmypy pandas, but other than that seems like a potentially good ideacastandassert- TBH this strikes me as more error-prone, and if pandas will expose types to users, then I think it'd be better to have the correct type revealed rather than having them docast/assertEven if
inplaceis removed in version 2, there are other places in the codebase where there's a parameter which changes the return type, so I do think finding a solution here is worthwhile.For now, I've gone with the first solution, though I will give some more thought to the second one