You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
C: 5, 0: Constant name "MyArray" doesn't conform to UPPER_CASE naming style (invalid-name)
E: 6,22: Instance of 'list' has no 'take' member (no-member)
C: 7, 0: Constant name "MyArray" doesn't conform to UPPER_CASE naming style (invalid-name)
Expected behavior
No error (and probably, no warning).
pylint --version output
pylint 1.8.4,
astroid 1.6.3
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)]
I suspect that pylint incorrectly thinks that MyArray is a constant; then assumes from the second assignment that it is a tuple; thus concludes it is a constant tuple. Under this assumption, the error message makes sense, but the assumption is incorrect.
The same errors appear in #1981; I have no idea whether this is related.
The text was updated successfully, but these errors were encountered:
PCManticore
changed the title
Incorrectly detected constant raises incorrect error E1101
numpy.empty is inferred as list, results in no-member
Apr 24, 2018
Thanks for the report!
The problem with constants is that pylint expects all the variables found at the global scope to respect a certain regular expression that conforms to a "constant", it expects all the variables to be upper case. That doesn't mean that the said variable needs to be a constant, it's just a matter of a convention that pylint uses.
The actual problem is the fact that we emit no-member for numpy.empty. We probably infer this as a list, while it seems it is in fact a special objects which certain attributes.
Steps to reproduce
pylint_bug.py.txt
Current behavior
Expected behavior
No error (and probably, no warning).
pylint --version output
I suspect that pylint incorrectly thinks that MyArray is a constant; then assumes from the second assignment that it is a tuple; thus concludes it is a constant tuple. Under this assumption, the error message makes sense, but the assumption is incorrect.
The same errors appear in #1981; I have no idea whether this is related.
The text was updated successfully, but these errors were encountered: