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

Instance attributes defined in parent classes can raise InferenceError #932

Closed
nelfin opened this issue Apr 7, 2021 · 0 comments · Fixed by #933
Closed

Instance attributes defined in parent classes can raise InferenceError #932

nelfin opened this issue Apr 7, 2021 · 0 comments · Fixed by #933
Milestone

Comments

@nelfin
Copy link
Contributor

nelfin commented Apr 7, 2021

Steps to reproduce

Inferring an attribute on a class instance where the instance attribute is defined in a base class will fail, but
inferring that same attribute via igetattr on an astroid.Instance will succeed.

import astroid
attr = astroid.extract_node("""
class Parent:
    def __init__(self):
        self.data = 123

class Test(Parent):
    pass
t = Test()
t.data
""")
# next(attr.infer())
# raises astroid.exceptions.InferenceError: Inference failed for <Attribute.data l.9 at 0x...>.
instance = next(attr.expr.infer())
print(next(instance.igetattr('data')))
# Const.int(value=123)

Discovered while debugging #904. I couldn't find an exact match for this issue before, but probably pylint-dev/pylint#960 is the same issue.

Current behavior

As above

Expected behavior

Inferring attribute should return Const.int(value=123)

python -c "from astroid import __pkginfo__; print(__pkginfo__.version)" output

2.6.0-dev0

nelfin added a commit to nelfin/astroid that referenced this issue Apr 7, 2021
Ref pylint-dev#932. The cause of this appears to be failing to specify the
lookupname on the inference context in BaseInstance.igetattr.
Additionally, the context path key was not set in a manner that matched
other usages. This appears to date back to at least 2015 when context
path keys were changed. The usage as a tuple instead of a node with
implict lookupname was changed last in 3d342e8 but the lookup key was
preserved throughout various changes since then.
nelfin added a commit to nelfin/astroid that referenced this issue Apr 7, 2021
Ref pylint-dev#932. The cause of this appears to be failing to specify the
lookupname on the inference context in BaseInstance.igetattr.
Additionally, the context path key was not set in a manner that matched
other usages. This appears to date back to at least 2015 when context
path keys were changed. The usage as a tuple instead of a node with
implict lookupname was changed last in 3d342e8 but the lookup key was
preserved throughout various changes since then.
nelfin added a commit to nelfin/astroid that referenced this issue Apr 8, 2021
Ref pylint-dev#932. The cause of this appears to be failing to specify the
lookupname on the inference context in BaseInstance.igetattr.
Additionally, the context path key was not set in a manner that matched
other usages. This appears to date back to at least 2015 when context
path keys were changed. The usage as a tuple instead of a node with
implict lookupname was changed last in 3d342e8 but the lookup key was
preserved throughout various changes since then.
nelfin added a commit to nelfin/astroid that referenced this issue May 12, 2021
Ref pylint-dev#932. The cause of this appears to be failing to specify the
lookupname on the inference context in BaseInstance.igetattr.
Additionally, the context path key was not set in a manner that matched
other usages. This appears to date back to at least 2015 when context
path keys were changed. The usage as a tuple instead of a node with
implict lookupname was changed last in 3d342e8 but the lookup key was
preserved throughout various changes since then.
nelfin added a commit to nelfin/astroid that referenced this issue May 12, 2021
Ref pylint-dev#932. The cause of this appears to be failing to specify the
lookupname on the inference context in BaseInstance.igetattr.
Additionally, the context path key was not set in a manner that matched
other usages. This appears to date back to at least 2015 when context
path keys were changed. The usage as a tuple instead of a node with
implict lookupname was changed last in 3d342e8 but the lookup key was
preserved throughout various changes since then.
@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
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants