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

Pylint unreliable when parsing property.setter code #8752

Closed
fdebrabander opened this issue Jun 7, 2023 · 3 comments
Closed

Pylint unreliable when parsing property.setter code #8752

fdebrabander opened this issue Jun 7, 2023 · 3 comments
Labels
Stale This issue is stale and will be deleted automatically if nothing happens Waiting on author Indicate that maintainers are waiting for a message of the author

Comments

@fdebrabander
Copy link

fdebrabander commented Jun 7, 2023

Bug description

Unfortunately cannot give the actual code triggering this issue and unable to reproduce at this moment with a simplified example code. The following example below is pseudo code to explain, not actual working code.

class Parent():
    def __init__():
        self._my_var = None

    @property
    def my_var(self):
        return self._my_var

    @my_var.setter
    def my_var(self, value):
        self._my_var = value


class SubClass(Parent):
    def __init__():
        self.var_1 = None
        self.var_2 = None
        self.var_3 = None
        self.var_4 = None
        self.var_5 = None
        self.var_6 = None
        self.var_7 = None


my_instance = SubClass()
my_instance.myvar = 1337

Observations:

  • Pylint does not always report an issue, roughly 20% of the invocations it will incorrectly report too-many-instance-attributes. Likely caused by some race condition when parsing a fairly large code base, pylint is used with jobs=0.
  • Suppressing this with disable=too-many-instance-attributes will then result in reporting of useless-supression, but again not with every invocation of pylint.
  • The class SubClass has 7 attributes, when pylint reports too-many-instance-attributes, it claims it has 8/7 attributes
  • After changing pylint's design_analysis.py method visit_classdef() and adding print(node.instance_attrs) you can see it included the "my_var" in the list of instance_attrs when pylint reports too-many-instance-attributes. It should not have included "my_var" in the list of node.instance_attrs.

In the actual code base that triggers this issue, all three code parts (two classes and instances of these classes) are in different python files.

Configuration

No response

Command used

pylint source_dir

Pylint output

my/source/file.py:60:0 R0902: Too many instance attributes (8/7) (too-many-instance-attributes)

Expected behavior

No issue expected.

Pylint version

pylint 2.17.3
astroid 2.15.4
Python 3.10.6

OS / Environment

Ubuntu 22.04

Additional dependencies

No response

@fdebrabander fdebrabander added the Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling label Jun 7, 2023
@jacobtylerwalls
Copy link
Member

jacobtylerwalls commented Jun 7, 2023

Thanks for the report! There have many substantial changes to inference in the v3 alphas. Can you reproduce against the main branches of pylint and astroid (or at least against astroid 3.0.0.a4?) I'm wondering if pylint-dev/astroid#2119 fixed the issue you see with my_var being counted among the instance attributes.

Likely caused by some race condition when parsing a fairly large code base, pylint is used with jobs=0.

Unfortunately, the fact that --jobs gives nondeterministic results is a known issue (#374). The biggest open wart in the project, IMO. We're looking at it for the v3 cycle.

@jacobtylerwalls jacobtylerwalls added Waiting on author Indicate that maintainers are waiting for a message of the author and removed Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling labels Jun 7, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Jul 6, 2023

This issue is stale because it has been open 4 weeks with no activity. Remove 'Stale' label or comment or this will be closed in a week.

@github-actions github-actions bot added the Stale This issue is stale and will be deleted automatically if nothing happens label Jul 6, 2023
@github-actions
Copy link
Contributor

This issue was closed because it has been stalled for five weeks with no activity.

@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Jul 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale This issue is stale and will be deleted automatically if nothing happens Waiting on author Indicate that maintainers are waiting for a message of the author
Projects
None yet
Development

No branches or pull requests

2 participants