Skip to content
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

false positive unnecessary-list-index-lookup for enumerate #7685

Merged
merged 7 commits into from Nov 13, 2022

Conversation

clavedeluna
Copy link
Collaborator

Type of Changes

Type
βœ“ πŸ› Bug fix

Description

Pylint will now not emit a unnecessary-list-index-lookup warning if the loop / comprehension is iterating over enumerate called with a start arg/kwarg.

Closes #7682

@coveralls
Copy link

coveralls commented Oct 27, 2022

Pull Request Test Coverage Report for Build 3452558221

  • 27 of 29 (93.1%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.004%) to 95.378%

Changes Missing Coverage Covered Lines Changed/Added Lines %
pylint/checkers/refactoring/refactoring_checker.py 27 29 93.1%
Totals Coverage Status
Change from base Build 3452308194: -0.004%
Covered Lines: 17315
Relevant Lines: 18154

πŸ’› - Coveralls

@github-actions

This comment has been minimized.

@Pierre-Sassoulas Pierre-Sassoulas added False Positive 🦟 A message is emitted but nothing is wrong with the code Needs backport Needs to be cherry-picked on the current patch version by a pylint's maintainer labels Oct 28, 2022
@Pierre-Sassoulas Pierre-Sassoulas added this to the 2.15.6 milestone Oct 28, 2022
Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the fix @clavedeluna. I think we can handle the false negative with start=0 too.

@@ -0,0 +1,3 @@
``unnecessary-list-index-lookup`` will not be emitted if ``enumerate`` is called with a `start` arg or kwarg.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
``unnecessary-list-index-lookup`` will not be emitted if ``enumerate`` is called with a `start` arg or kwarg.
``unnecessary-list-index-lookup`` will not be wrongly emitted if ``enumerate`` is called with ``start``.

Comment on lines 99 to 100
for idx, val in enumerate(series, start=2):
print(my_list[idx])
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
for idx, val in enumerate(series, start=2):
print(my_list[idx])
for idx, val in enumerate(series, start=2):
print(my_list[idx])
for idx, val in enumerate(series, 2):
print(my_list[idx])
for idx, val in enumerate(series, start=0):
print(my_list[idx]) # [unnecessary-list-index-lookup]
for idx, val in enumerate(series, 0):
print(my_list[idx]) # [unnecessary-list-index-lookup]

`enumerate([1,2,3], 1)`
"""
if len(node.iter.args) > 1:
# We assume the second argument to `enumerate` is the `start` arg.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
# We assume the second argument to `enumerate` is the `start` arg.
# We assume the second argument to `enumerate` is the `start` arg.
# It's a reasonable assumption for now as it's the only possible argument:
# https://docs.python.org/3/library/functions.html#enumerate


return not start_val == 0

return False
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually tried to refactor this method because it looks like a bunch of duplicate code, but:

  1. refactoring wouldn't allow for some short-circuting which seems best for performance
  2. args v. kwargs has sliiightly different needs, .value.operand v. .operand etc

@clavedeluna
Copy link
Collaborator Author

Thank you for the fix @clavedeluna. I think we can handle the false negative with start=0 too.

good call, I also went ahead and added calls for negative start value which made the logic more robust albeit a bit more complicated

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great ! πŸ‘

@Pierre-Sassoulas
Copy link
Member

The failing test on python 3.11 seems genuine

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thank you !

@clavedeluna
Copy link
Collaborator Author

primer doesn't wanna prime 😞

@clavedeluna
Copy link
Collaborator Author

@DanielNoord would you be able to provide a bit more info on the exception? was there a stack trace? Or maybe something I could minimally reproduce and add a test for? Great catch! No wonder my other PRs have no issues with the primer

@DanielNoord
Copy link
Collaborator

@DanielNoord would you be able to provide a bit more info on the exception? was there a stack trace? Or maybe something I could minimally reproduce and add a test for? Great catch! No wonder my other PRs have no issues with the primer

It's actually quite easy to reproduce this yourself locally. Just run:

python tests/primer/__main__.py prepare --clone
python tests/primer/__main__.py run --type=pr

It will take some time to get to pandas but the exception will be there.
You can also look at the pandas-dev/pandas/pandas/core/indexes/multi.py file as that is where the issue seems to be.

@clavedeluna
Copy link
Collaborator Author

glad I opened #7714

@clavedeluna
Copy link
Collaborator Author

Thanks @DanielNoord for getting me to finally run the primer locally. I must've done too many of the CI steps and got stuck initially. The error was easy to spot and fix, so I hope everything passes now!

@clavedeluna
Copy link
Collaborator Author

😒 primer, I don't think it has anything to do with this PR

@Pierre-Sassoulas
Copy link
Member

A case study for #7738

@github-actions

This comment has been minimized.

Copy link
Member

@Pierre-Sassoulas Pierre-Sassoulas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Small nitpick, it's ready to go otherwise, nice fix @clavedeluna πŸŽ‰

doc/whatsnew/fragments/7682.bugfix Outdated Show resolved Hide resolved
@github-actions
Copy link
Contributor

πŸ€– According to the primer, this change has no effect on the checked open source code. πŸ€–πŸŽ‰

This comment was generated for commit bf59f13

@Pierre-Sassoulas Pierre-Sassoulas merged commit 131b315 into pylint-dev:main Nov 13, 2022
Pierre-Sassoulas added a commit that referenced this pull request Nov 16, 2022
* do not report unnecessary list index lookup if start arg is passed

* account for calling start with 0 or negative num

Co-authored-by: Pierre Sassoulas <pierre.sassoulas@gmail.com>
@Pierre-Sassoulas Pierre-Sassoulas added Backported and removed Needs backport Needs to be cherry-picked on the current patch version by a pylint's maintainer labels Nov 16, 2022
Pierre-Sassoulas added a commit that referenced this pull request Nov 17, 2022
* do not report unnecessary list index lookup if start arg is passed

* account for calling start with 0 or negative num

Co-authored-by: Pierre Sassoulas <pierre.sassoulas@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Backported False Positive 🦟 A message is emitted but nothing is wrong with the code
Projects
None yet
Development

Successfully merging this pull request may close these issues.

unnecessary-list-index-lookup is falsely being reported when there is a start index
5 participants