-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Expand RUF015
rule for list(iterable).pop(0)
idiom
#9190
Comments
RUF015
rule for list(iterable).pop() idiomRUF015
rule for list(iterable).pop()
idiom
👍 Makes sense! |
>>> iterable = [1,2]
>>> list(iterable).pop()
2
>>> next(iter(iterable))
1
>>> |
Oh, oops, the |
Oh whoops. Good catch, I misremembered the default arg of pop. This still applies to |
RUF015
rule for list(iterable).pop()
idiomRUF015
rule for list(iterable).pop(0)
idiom
Using -list(iterable).pop(0)
+next(iter(iterable))
-list(iterable).pop()
+next(reversed(iterable)) |
Oh, great point! |
a = iter(range(10))
b = reversed(a) will return an error. |
oh right, this is a tricky one. However, I'm not sure %timeit deque(range(10000), maxlen=1).pop()
88.7 µs ± 8.44 µs per loop (mean ± std. dev. of 7 runs, 10,000 loops each)
%timeit list(range(10000)).pop()
73.8 µs ± 252 ns per loop (mean ± std. dev. of 7 runs, 10,000 loops each) |
Yeah, this is more about memory management than speed. I think we agree that the |
(this should be an unsafe fix) |
I am a beginner in Rust and would like to contribute. Can I take this up? |
Sure!
So, currently the implementation takes in an This will require updating the function signature to now take any The fix for this rule is already unsafe and it would help expand on the fix safety documentation of the rule with why this fix is unsafe w.r.t. the new code. Hope this helps, feel free to ask any other questions that you might have. I'll assign this issue to you but don't feel any pressure to complete this :) |
Since there was no activity on this issue yet (followed it for the last 2 weeks), I stepped ahead and provided a fix in #10148. I hope I interpreted the inactivity on this ticket correctly and didn't steal someones chance. @dhruvmanila, @charliermarsh, do you mind reviewing the PR? Thanks a lot. |
…0148) ## Summary Currently, rule `RUF015` is not able to detect the usage of `list(iterable).pop(0)` falling under the category of an _unnecessary iterable allocation for accessing the first element_. This PR wants to change that. See the underlying issue for more details. * Provide extension to detect `list(iterable).pop(0)`, but not `list(iterable).pop(i)` where i > 1 * Update corresponding doc ## Test Plan * `RUF015.py` and the corresponding snap file were extended such that their correspond to the new behaviour Closes #9190 --- PS: I've only been working on this ticket as I haven't seen any activity from issue assignee @rmad17, neither in this repo nor in a fork. I hope I interpreted his inactivity correctly. Didn't mean to steal his chance. Since I stumbled across the underlying problem myself, I wanted to offer a solution as soon as possible.
@robincaloudis Thanks for taking it up, I was not able to look into it despite asking for the ticket to be assigned. |
…tral-sh#10148) ## Summary Currently, rule `RUF015` is not able to detect the usage of `list(iterable).pop(0)` falling under the category of an _unnecessary iterable allocation for accessing the first element_. This PR wants to change that. See the underlying issue for more details. * Provide extension to detect `list(iterable).pop(0)`, but not `list(iterable).pop(i)` where i > 1 * Update corresponding doc ## Test Plan * `RUF015.py` and the corresponding snap file were extended such that their correspond to the new behaviour Closes astral-sh#9190 --- PS: I've only been working on this ticket as I haven't seen any activity from issue assignee @rmad17, neither in this repo nor in a fork. I hope I interpreted his inactivity correctly. Didn't mean to steal his chance. Since I stumbled across the underlying problem myself, I wanted to offer a solution as soon as possible.
I just saw another method of accessing the first element of an iterable / dictionary key that is very inefficient. Currently, this is not detected by RUF015 which we have enabled. We should expand RUF015 to cover this idiom. A minimal problematic example is found below.
It should be
which would not require iterating through the entire iterable just to retrieve the first element. Expanding the autofix to cover this would be helpful as well.
The text was updated successfully, but these errors were encountered: