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 seems to ignore any typings #8027

Closed
Amadeus82 opened this issue Jan 6, 2023 · 3 comments
Closed

pylint seems to ignore any typings #8027

Amadeus82 opened this issue Jan 6, 2023 · 3 comments
Labels
Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling

Comments

@Amadeus82
Copy link

Bug description

The following short code snippet shows that pylint ignores the return type signatures of methods and instead tries to predict the effective runtime type of a variable:
Yes, 'a' is initialized as None, but it is later reassigned with a different value, which is ignored by pylint, making it assume that 'b' must in the end still be None and thus both, unsubscriptable and not supporting membership tests (which is both wrong).

from typing import Optional, Dict

class A:
    a: Optional[Dict[str, int]] = None # error
    # a: Optional[Dict[str, int]] = {} # works

    @staticmethod
    def my_method() -> Dict[str, int]:
        A.a = {'a': 2}
        return A.a

b = A.my_method()
print(b['a'])
print('a' in b)

Configuration

No response

Command used

pylint --disable=C,R main.py

Pylint output

************* Module main
main.py:13:6: E1136: Value 'b' is unsubscriptable (unsubscriptable-object)
main.py:14:13: E1135: Value 'b' doesn't support membership test (unsupported-membership-test)

------------------------------------------------------------------
Your code has been rated at 0.00/10 (previous run: 0.00/10, +0.00)

Expected behavior

Python is a dynamic language which makes it particularly challenging to predict the potential runtime type of a variable at any given time - I totally understand that. But then again, even with type hints clearly stating that the return value of my_func will ALWAYS be a dict, pylint still assumes it must be None. I would say, pylint must either rely on given type hints and or apply a sophisticated and reliable method of determining whether a variable can really be something that is REALLY non subscriptable and that does not support membership tests.

Please also consider the following sample:

class A:
    a = None

    @staticmethod
    def do_some_pretty_predictable_shit():
        setattr(A, random.choice(['a']), {'a': 2})

    @staticmethod
    def my_method() -> Dict[str, int]:
        A.do_some_pretty_predictable_shit()
        return A.a

b = A.my_method()
print(b['a'])
print('a' in b)

Again, b will ALWAYS be subscriptable and support membership tests. Are you ready for this kind of stuff?
Now your static code analyzer needs to understand what random choice does. What if a binary third
party library is thrown into the mix?

Pylint version

pylint 2.15.9

OS / Environment

Windows 10

Additional dependencies

No response

@Amadeus82 Amadeus82 added the Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling label Jan 6, 2023
@Pierre-Sassoulas
Copy link
Member

Duplicate of #4813

@Pierre-Sassoulas Pierre-Sassoulas marked this as a duplicate of #4813 Jan 6, 2023
@Pierre-Sassoulas Pierre-Sassoulas closed this as not planned Won't fix, can't repro, duplicate, stale Jan 6, 2023
@Pierre-Sassoulas
Copy link
Member

But thank you for the detailed issue :)

@Amadeus82
Copy link
Author

Amadeus82 commented Jan 6, 2023

You are welcome and sorry for not realizing that a more or less identical issue was already reported. ;-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Needs triage 📥 Just created, needs acknowledgment, triage, and proper labelling
Projects
None yet
Development

No branches or pull requests

2 participants