-
-
Notifications
You must be signed in to change notification settings - Fork 19.4k
STYLE, TYP Turn black formatter off for overloads #40973
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
STYLE, TYP Turn black formatter off for overloads #40973
Conversation
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can the noqa be made specific, i think # noqa:F501,E704
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.
done, thanks!
|
I think I prefer the status quo |
|
Sure, let's stick to that then 👍 |
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