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

E1101 false positive if exception variable reused with a different type #2802

Closed
dberzano opened this issue Mar 7, 2019 · 2 comments
Closed

Comments

@dberzano
Copy link

dberzano commented Mar 7, 2019

Steps to reproduce

Sample code, test.py:

"""Reproducer."""

def fun():
    """Description."""
    try:
        pass
    except Exception as exc:
        raise exc
    try:
        pass
    except OSError as exc:
        if exc.errno == 42:
            pass

then run:

pylint test.py

Current behavior

exc is used first with Exception type, and then reused later on as OSError (which has errno). pylint is confused and claims exc has no errno because it still thinks it's of type Exception:

test.py:12:11: E1101: Instance of 'Exception' has no 'errno' member (no-member)

Expected behavior

pylint correctly identifies the type of the variable the second time it's used in an except block.

pylint --version output

pylint 2.3.1
astroid 2.2.4
Python 3.7.2 (default, Feb 12 2019, 08:15:36)
[Clang 10.0.0 (clang-1000.11.45.5)]

Bisect note: works with pylint 2.2.3, breaks with at least 2.3.0.

This relates to alidock/alidock#105.

@PCManticore
Copy link
Contributor

Hey @dberzano Thanks for creating the issue! This is already fixed in astroid's master and I just backported those changes to astroid 2.2 I'll do a 2.2.5 release in a bit so this issue should go away once that's done.

@dberzano
Copy link
Author

dberzano commented Mar 8, 2019

Thanks! This explains why the issue was still there yesterday even with pip install pylint astroid --pre -U.

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

No branches or pull requests

2 participants