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

error during inference of class inheriting from another with mod.Type format #904

Closed
ltcmelo opened this issue Feb 19, 2021 · 0 comments · Fixed by #934
Closed

error during inference of class inheriting from another with mod.Type format #904

ltcmelo opened this issue Feb 19, 2021 · 0 comments · Fixed by #934
Labels
Milestone

Comments

@ltcmelo
Copy link
Contributor

ltcmelo commented Feb 19, 2021

Consider package a level with a class Model defined in level's __init__.py file.

class Model:
    data: int = 1

If a class Test inherits from Model as class Test(Model), and Model comes from from level import Model, then inferring Test.data works fine (below, A is an alias for astroid).

Screen Shot 2021-02-19 at 09 41 09

However, if a Test inherits from Model as class Test(level.Model) and level comes from import level, then inference triggers an exception.

Screen Shot 2021-02-19 at 09 42 09

nelfin added a commit to nelfin/astroid that referenced this issue Apr 7, 2021
Ref pylint-dev#904. `getattr` attempts to find values on `self.ancestors`, which
infers each node listed in `self.bases`. Removing or resetting the
context passed to ancestors allows it to infer the nodes, but opens up
the possibility of cycles through recursive definitions. We should be
able to infer the value of the base node correctly as a `ClassDef`. The
root of this issue stems from the fact that `infer_attribute` attempts
to temporarily set `context.boundnode`, but when unwrapping its changes
it sets the `boundnode` to `None` instead of its previous value, which
loses state and causes the inference of the `Attribute` node to have a
duplicate key: once when looking up the class definition (which should
have `boundnode = None`), and once when inferring the (other) attribute
value (which should not have `boundnode = None`)
nelfin added a commit to nelfin/astroid that referenced this issue Apr 7, 2021
Ref pylint-dev#904. `getattr` attempts to find values on `self.ancestors`, which
infers each node listed in `self.bases`. Removing or resetting the
context passed to ancestors allows it to infer the nodes, but opens up
the possibility of cycles through recursive definitions. We should be
able to infer the value of the base node correctly as a `ClassDef`. The
root of this issue stems from the fact that `infer_attribute` attempts
to temporarily set `context.boundnode`, but when unwrapping its changes
it sets the `boundnode` to `None` instead of its previous value, which
loses state and causes the inference of the `Attribute` node to have a
duplicate key: once when looking up the class definition (which should
have `boundnode = None`), and once when inferring the (other) attribute
value (which should not have `boundnode = None`)
nelfin added a commit to nelfin/astroid that referenced this issue Apr 8, 2021
Ref pylint-dev#904. `getattr` attempts to find values on `self.ancestors`, which
infers each node listed in `self.bases`. Removing or resetting the
context passed to ancestors allows it to infer the nodes, but opens up
the possibility of cycles through recursive definitions. We should be
able to infer the value of the base node correctly as a `ClassDef`. The
root of this issue stems from the fact that `infer_attribute` attempts
to temporarily set `context.boundnode`, but when unwrapping its changes
it sets the `boundnode` to `None` instead of its previous value, which
loses state and causes the inference of the `Attribute` node to have a
duplicate key: once when looking up the class definition (which should
have `boundnode = None`), and once when inferring the (other) attribute
value (which should not have `boundnode = None`)
nelfin added a commit to nelfin/astroid that referenced this issue May 12, 2021
Ref pylint-dev#904. `getattr` attempts to find values on `self.ancestors`, which
infers each node listed in `self.bases`. Removing or resetting the
context passed to ancestors allows it to infer the nodes, but opens up
the possibility of cycles through recursive definitions. We should be
able to infer the value of the base node correctly as a `ClassDef`. The
root of this issue stems from the fact that `infer_attribute` attempts
to temporarily set `context.boundnode`, but when unwrapping its changes
it sets the `boundnode` to `None` instead of its previous value, which
loses state and causes the inference of the `Attribute` node to have a
duplicate key: once when looking up the class definition (which should
have `boundnode = None`), and once when inferring the (other) attribute
value (which should not have `boundnode = None`)
cdce8p added a commit to cdce8p/astroid that referenced this issue May 22, 2021
Squashed commit of the following:

commit e402894
Author: Andrew Haigh <[email protected]>
Date:   Thu May 13 07:51:24 2021 +1000

    Update changelog

commit 4c7097a
Author: Andrew Haigh <[email protected]>
Date:   Wed Apr 7 09:09:45 2021 +1000

    Fix inference cycle in getattr when a base is an astroid.Attribute

    Ref pylint-dev#904. `getattr` attempts to find values on `self.ancestors`, which
    infers each node listed in `self.bases`. Removing or resetting the
    context passed to ancestors allows it to infer the nodes, but opens up
    the possibility of cycles through recursive definitions. We should be
    able to infer the value of the base node correctly as a `ClassDef`. The
    root of this issue stems from the fact that `infer_attribute` attempts
    to temporarily set `context.boundnode`, but when unwrapping its changes
    it sets the `boundnode` to `None` instead of its previous value, which
    loses state and causes the inference of the `Attribute` node to have a
    duplicate key: once when looking up the class definition (which should
    have `boundnode = None`), and once when inferring the (other) attribute
    value (which should not have `boundnode = None`)
nelfin added a commit to nelfin/astroid that referenced this issue May 22, 2021
Ref pylint-dev#904. `getattr` attempts to find values on `self.ancestors`, which
infers each node listed in `self.bases`. Removing or resetting the
context passed to ancestors allows it to infer the nodes, but opens up
the possibility of cycles through recursive definitions. We should be
able to infer the value of the base node correctly as a `ClassDef`. The
root of this issue stems from the fact that `infer_attribute` attempts
to temporarily set `context.boundnode`, but when unwrapping its changes
it sets the `boundnode` to `None` instead of its previous value, which
loses state and causes the inference of the `Attribute` node to have a
duplicate key: once when looking up the class definition (which should
have `boundnode = None`), and once when inferring the (other) attribute
value (which should not have `boundnode = None`)
hippo91 pushed a commit that referenced this issue May 24, 2021
)

* Fix inference cycle in getattr when a base is an astroid.Attribute

Ref #904. `getattr` attempts to find values on `self.ancestors`, which
infers each node listed in `self.bases`. Removing or resetting the
context passed to ancestors allows it to infer the nodes, but opens up
the possibility of cycles through recursive definitions. We should be
able to infer the value of the base node correctly as a `ClassDef`. The
root of this issue stems from the fact that `infer_attribute` attempts
to temporarily set `context.boundnode`, but when unwrapping its changes
it sets the `boundnode` to `None` instead of its previous value, which
loses state and causes the inference of the `Attribute` node to have a
duplicate key: once when looking up the class definition (which should
have `boundnode = None`), and once when inferring the (other) attribute
value (which should not have `boundnode = None`)

* Update changelog
@Pierre-Sassoulas Pierre-Sassoulas added this to the 2.5.7 milestone May 24, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants