Skip to content

Conversation

clavedeluna
Copy link
Contributor

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.

@jacobtylerwalls jacobtylerwalls self-requested a review October 27, 2022 23:18
@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
Contributor 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
Contributor 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
Contributor Author

primer doesn't wanna prime 😞

@clavedeluna
Copy link
Contributor 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
Contributor Author

glad I opened #7714

@clavedeluna
Copy link
Contributor 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
Contributor Author

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

@Pierre-Sassoulas
Copy link
Member

A case study for #7738

@jacobtylerwalls jacobtylerwalls removed the Blocked 🚧 Blocked by a particular issue label Nov 12, 2022
@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 πŸŽ‰

@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 <[email protected]>
@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 <[email protected]>
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