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 incorrectly flags as unused-import things that are used in type comments #3112

Closed
chadrik opened this issue Sep 23, 2019 · 5 comments
Closed
Labels
False Positive 🦟 A message is emitted but nothing is wrong with the code

Comments

@chadrik
Copy link

chadrik commented Sep 23, 2019

This issue was supposed to have been fixed in #1063, but it appears that it was not completely fixed.

Current Behavior

The following example works correctly, and all imports from the typing module are correctly identified as being "used":

"""docstring"""

from typing import Iterable, List, Sequence

def function(arg1, arg2):
    # type: (Iterable, List) -> Sequence
    """docstring"""
    print(arg1, arg2)
$ pylint ./pylint_test2.py 

------------------------------------
Your code has been rated at 10.00/10

But use of the one-arg-per-line form of pep 484 is not properly detected by pylint:

"""docstring"""

from typing import Iterable, List, Sequence

def function(arg1,  # type: Iterable
             arg2  # type: List
            ):
    # type: (...) -> Sequence
    """docstring"""
    print(arg1, arg2)
$ pylint ./pylint_test1.py 
************* Module pylint_test1
pylint_test1.py:3:0: W0611: Unused Iterable imported from typing (unused-import)
pylint_test1.py:3:0: W0611: Unused List imported from typing (unused-import)

-------------------------------------------------------------------
Your code has been rated at 3.33/10 (previous run: -3.33/10, +6.67

Expected Behavior

There should be no error: all items should be detected as being used, as in the first example

Environment

$ pylint --version
pylint 2.3.1
astroid 2.2.5
Python 3.7.3 (default, Jun 19 2019, 07:40:15) 
[Clang 10.0.0 (clang-1000.11.45.5)]

I also tried with python 3.6.1. Same issue.

@chadrik
Copy link
Author

chadrik commented Sep 23, 2019

Wow. Thanks for fixing that so fast!

@davidgiga1993
Copy link

I'm still having the same issue with python 3.7.4 on linux:

from typing import Optional

class A:
    def __init__(self):
        self.field = None  # type: Optional[str]
pylint  Test.py
************* Module Test
...
Test.py:1:0: W0611: Unused Optional imported from typing (unused-import)

pylint --version
pylint 2.4.2
astroid 2.3.1
Python 3.7.4 (default, Jul 23 2019, 10:08:33)
[GCC 4.8.5]

Interestingly I don't get this issue on windows with python 3.7.3:

pylint --version
pylint 2.4.2
astroid 2.3.1
Python 3.7.3 (v3.7.3:ef4ec6ed12, Mar 25 2019, 21:26:53) [MSC v.1916 32 bit (Intel)]

Any ideas what could cause this issue?

@gaborbernat
Copy link

"""yes"""
from datetime import datetime
from typing import Optional, Any


def magic(alpha, beta, gamma):
    # type: (str, Optional[str], Optional[datetime]) -> Any
    """going strong"""
    return alpha, beta, gamma
************* Module test
test.py:2:0: W0611: Unused datetime imported from datetime (unused-import)

------------------------------------------------------------------
Your code has been rated at 7.50/10 (previous run: 7.50/10, +0.00)
pylint --version                                                                                                                                               790ms  Thu 31 Oct 10:20:47 2019
pylint 2.4.3
astroid 2.3.2
Python 3.8.0 (default, Oct 15 2019, 18:49:26)
[Clang 11.0.0 (clang-1100.0.33.8)]

See the above also throws this.

@PCManticore
Copy link
Contributor

@davidgiga1993 The fix was released as part of 2.4.3, it seems you are using 2.4.2. Can you also give it a try with 2.4.3 and see if it works for you?

@gaborbernat Thanks, I can reproduce that one using the latest version.

@PCManticore PCManticore reopened this Nov 8, 2019
PCManticore added a commit that referenced this issue Nov 8, 2019
The previous code was assuming that only ``typing`` names need to be
exempted, but we need to do that for the rest of the type comment
names as well.

Close #3112
@PCManticore
Copy link
Contributor

Thanks for that additional example @gaborbernat This is now fixed in master and the 2.4 branch, will be released as 2.4.4 soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
False Positive 🦟 A message is emitted but nothing is wrong with the code
Projects
None yet
Development

No branches or pull requests

5 participants