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

Make consider-iterating-dictionary consider memb. check #4997

Merged
merged 9 commits into from Sep 14, 2021

Conversation

DanielNoord
Copy link
Collaborator

@DanielNoord DanielNoord commented Sep 13, 2021

  • Add yourself to CONTRIBUTORS if you are a new contributor.
  • Add a ChangeLog entry describing what your PR does.
  • If it's a new feature, or an important bug fix, add a What's New entry in
    doc/whatsnew/<current release.rst>.
  • Write a good description on what the PR does.

Type of Changes

Type
✨ New feature

Description

This closes #4069

The original issue talked about a new checker but I felt this fitted quite nicely within the description of the original checker.
I also removed a redundant check in the line before the message was added.

@coveralls
Copy link

coveralls commented Sep 13, 2021

Pull Request Test Coverage Report for Build 1233871538

  • 4 of 4 (100.0%) changed or added relevant lines in 1 file are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-0.001%) to 93.083%

Totals Coverage Status
Change from base Build 1232904023: -0.001%
Covered Lines: 13256
Relevant Lines: 14241

💛 - Coveralls

@cdce8p cdce8p added the Enhancement ✨ Improvement to a component label Sep 13, 2021
@cdce8p cdce8p added this to the 2.11.0 milestone Sep 13, 2021
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.

👍 nice false negative fixed !

@DanielNoord
Copy link
Collaborator Author

@Pierre-Sassoulas Any idea why your merge-commit made it fail the tests? Seems strange..

@Pierre-Sassoulas
Copy link
Member

I don't know, we did not change anything for invalid-name on the main branch. This is very strange.

@cdce8p
Copy link
Member

cdce8p commented Sep 14, 2021

Really strange. I though a rebase might fix it, but apparently not 🤷🏻‍♂️
Tested the commits on my personal dev branch, and the invalid-name doesn't happen.

@cdce8p
Copy link
Member

cdce8p commented Sep 14, 2021

This seems to be caused by pylint-dev/astroid#979

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.

Maybe a false negative for invalid-name that was fixed in the latest version of astroid ? var is an invalid name (bad names list), so I think we can disable it or change var name to something else

# pylint: disable=missing-docstring, expression-not-assigned, too-few-public-methods, no-member, import-error, no-self-use, line-too-long, useless-object-inheritance, unnecessary-comprehension
# pylint: disable=missing-docstring, expression-not-assigned, too-few-public-methods
# pylint: disable=no-member, import-error, no-self-use, line-too-long, useless-object-inheritance
# pylint: disable=unnecessary-comprehension, use-dict-literal
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
# pylint: disable=unnecessary-comprehension, use-dict-literal
# pylint: disable=unnecessary-comprehension, use-dict-literal,invalid-name

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 think it would be better to change the name than add an additional disable here.
However, I don't see var in bad-names in ./pylintrc.

Furthermore, this doesn't explain why this is only being thrown in the CI. The tests pass locally for me (and I think also for @cdce8p). Probably should try and investigate what is exactly causing this before adding a disable.
@cdce8p seems to have an idea, or at least has located the source

Copy link
Contributor

Choose a reason for hiding this comment

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

I was able to replicate the failure when running under tox: (tox -e py36 -- -k consider_iterating). Sorry about jumping in, I was just pinged by the mention of pylint-dev/astroid#979

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 forgot to add --recreate, which you probably did some time before. Can now indeed reproduce.

I can change this to another variable name. Can somebody tell me where pylint is getting the bad-names list from? I'm probably overlooking something..

Edit: Got it. It is because var is lowercase, uppercase fixes the issue. Pushing now!

Copy link
Contributor

Choose a reason for hiding this comment

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

As to why this shows up after that merge on astroid, my reading of https://github.com/PyCQA/pylint/blob/bc95cd34071ec2e71de5bca8ff95cc9b88e23814/pylint/checkers/base.py#L1975-L1984 is that invalid-name is only emitted if the Assign .value can be inferred. Since Compare nodes are only just now inferred, these popped up.

Copy link
Member

Choose a reason for hiding this comment

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

Seems I mixed up invalid-name with disallowed-name myself.

var is fine to us, but here it's inferred as constant which should be uppercase (like @DanielNoord mentioned).
pylint-dev/astroid#979 added additional inference for compare nodes which is why these can now correctly be inferred as constants. Thus invalid-name is emitted now.

Sorry for the ping @nelfin.

Copy link
Member

@cdce8p cdce8p left a comment

Choose a reason for hiding this comment

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

Some last comments

pylint/checkers/refactoring/recommendation_checker.py Outdated Show resolved Hide resolved
if (
isinstance(node.parent, (nodes.For, nodes.Comprehension))
or isinstance(node.parent, nodes.Compare)
and any(op for op, _ in node.parent.ops if op == "in")
Copy link
Member

Choose a reason for hiding this comment

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

It's a bit constructed, but technically possible. No warning should be emitted for

var = [1, 2] == {}.keys() in {False}

It should be enough to add an additional condition to the if clause, testing that the second value of ops is in fact the call node itself.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Some day I want to know as much about Python as you seem to do and be able to come up with these tests 😄

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for the compliment ❤️

DanielNoord and others added 2 commits September 14, 2021 15:33
Co-authored-by: Marc Mueller <30130371+cdce8p@users.noreply.github.com>
@cdce8p cdce8p merged commit af407c7 into pylint-dev:main Sep 14, 2021
@DanielNoord DanielNoord deleted the consider-iterating branch September 14, 2021 16:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Enhancement ✨ Improvement to a component
Projects
None yet
Development

Successfully merging this pull request may close these issues.

consider-dictionary-membership
5 participants