-
Notifications
You must be signed in to change notification settings - Fork 15
MAINT: Bump ruff to v0.16
#234
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
Changes from all commits
5289f58
127d3fc
277448d
1eb54cc
2ff0c89
93229ce
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -142,7 +142,7 @@ def roll( | |
| See its docstring for more information. | ||
| """ | ||
| if not isinstance(shift, int | tuple): | ||
| raise ValueError( | ||
| raise TypeError( | ||
|
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Strictly speaking, this is a backwards incompatible change. The spec does not mandate a specific exception class, thus we can accept the backwards compat break and make change it to a more appropriate exception type, as done here. |
||
| f"`shift` can only be an int or a tuple, got {type(shift)=} instead." | ||
| ) | ||
| return Array._new(np.roll(x._array, shift, axis=axis), device=x.device) | ||
|
|
||
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 pattern (repeated multiple times below) looks usunsual enough, thus I looked a bit more carefully.
The whole
_normalize_two_argsdance is needed to work around 0D numpy arrays lacking functionality:self._normalize_two_args(self, other)return a pair of-strictarrays, wher each element is either the original argument, or a new-strictarray with its internal_arrayattribute promoted from 0D to 1D. Then, next line,{self, _self}._array.__op__(other._array)does the__op__with numpy attrbutes, and the next line isreturn self.__class__._new(res, device=self.device), so we return a new-strictarray object.Either way, we do operations with numpy
_arrayattributes and always return a new-strictarray object---the actual operations are done with numpy_arrayattributes, and this is where it is decided if the actual operation is in-place or not.Before this patch, the code did potentially mutate
self, which was harmless because we always a new object constructed inreturn self.__class__._new.This patch only makes the intent clearer by renaming the potentially mutated object.
Conclusion: it is a good change.