I am running Pylint on a Python project. Pylint makes many complaints about being unable to find NumPy members. How can I avoid this while avoiding skipping membership checks?
From the code:
import numpy as np
print np.zeros([1, 4])
Which, when ran, I get the expected:
[[ 0. 0. 0. 0.]]
However, Pylint gives me this error:
E: 3, 6: Module 'numpy' has no 'zeros' member (no-member)
For versions, I am using Pylint 1.0.0 (astroid 1.0.1, common 0.60.0) and trying to work with NumPy 1.8.0.
On
There have been many different bugs reported about this over the past few years i.e. https://bitbucket.org/logilab/pylint/issue/58/false-positive-no-member-on-numpy-imports
I'd suggest disabling for the lines where the complaints occur.
# pylint: disable=E1103
print np.zeros([1, 4])
# pylint: enable=E1103
I've been working on a patch to Pylint to solve the issue with dynamic members in libraries such as NumPy.
It adds a "dynamic-modules" option which forces to check if members exist during runtime by making a real import of the module. See Issue #413 in logilab/pylint. There is also a pull request; see link in one of the comments.
On
This solution worked for me.
Basically, go to select the gear icon from the bottom left → Setting → Workspace Setting → Extension → Python Configuration → click on any Settings.json → add this in the file "python.linting.pylintArgs" : [ "--extension-pkg-whitelist=numpy" ]
I am using Visual Studio Code 1.27.2.
On
I was getting the same error for a small NumPy project I was working on and decided that ignoring the NumPy modules would do just fine. I created a .pylintrc file with:
$ pylint --generate-rcfile > ~/.pylintrc
And following paduwan's and j_houg's advice I modified the following sectors:
[MASTER]
# A comma-separated list of package or module names from where C extensions may
# be loaded. Extensions are loading into the active Python interpreter and may
# run arbitrary code
extension-pkg-whitelist=numpy
and
[TYPECHECK]
# List of module names for which member attributes should not be checked
# (useful for modules/projects where namespaces are manipulated during runtime
# and thus existing member attributes cannot be deduced by static analysis. It
# supports qualified module names, as well as Unix pattern matching.
ignored-modules=numpy
# List of classes names for which member attributes should not be checked
# (useful for classes with attributes dynamically set). This supports can work
# with qualified names.
ignored-classes=numpy
and it "fixed" my issue.
On
A quick answer: update Pylint to 1.7.1 (use conda-forge provided Pylint 1.7.1 if you use Conda to manage packages).
I found a similar issue in Pylint GitHub here and someone replied everything getting OK after updating to 1.7.1.
On
Since this is the top result in Google Search and it gave me the impression that you have to ignore those warnings in all files:
The problem has actually been fixed in the sources of Pylint/astroid last month https://bitbucket.org/logilab/astroid/commits/83d78af4866be5818f193360c78185e1008fd29e but are not yet in the Ubuntu packages.
To get the sources, just
hg clone https://bitbucket.org/logilab/pylint/
hg clone https://bitbucket.org/logilab/astroid
mkdir logilab && touch logilab/__init__.py
hg clone http://hg.logilab.org/logilab/common logilab/common
cd pylint && python setup.py install
whereby the last step will most likely require a sudo and of course you need Mercurial to clone.
On
I had the same issue here, even with the latest versions of all related packages (astroid 1.3.2, logilab_common 0.63.2, pylon 1.4.0).
The following solution worked like a charm: I added numpy to the list of ignored modules by modifying my pylintrc file, in the [TYPECHECK] section:
[TYPECHECK]
ignored-modules = numpy
Depending on the error, you might also need to add the following line (still in the [TYPECHECK] section):
ignored-classes = numpy
I had the same problem with a different module (kivy.properties) which is a wrapped C module like NumPy.
Using Visual Studio Code V1.38.0, the accepted solution stopped all linting for the project. So, while it did indeed remove the false-positive no-name-in-module, it didn't really improve the situation.
The best workaround for me was to use the --ignored-modules argument on the offending module. The trouble is, passing any argument via python.linting.pylintArgs wipes out the default Visual Studio Code settings, so you need to reset those also. That left me with the following settings.json file:
{
"python.pythonPath": "C:\\Python\\Python37\\python.exe",
"python.linting.pylintEnabled": true,
"python.linting.enabled": true,
"python.linting.pylintArgs": [
"--ignored-modules=kivy.properties",
"--disable=all",
"--enable=F,E,unreachable,duplicate-key,unnecessary-semicolon,global-variable-not-assigned,unused-variable,binary-op-exception,bad-format-string,anomalous-backslash-in-string,bad-open-mode"
]
}
I had this problem with NumPy, SciPy, sklearn, nipy, etc., and I solved it by wrapping epylint like so:
#!/usr/bin/python
"""
Synopsis: epylint wrapper that filters a bunch of false-positive warnings and errors
Author: DOHMATOB Elvis Dopgima <[email protected]> <[email protected]>
"""
import os
import sys
import re
from subprocess import Popen, STDOUT, PIPE
NUMPY_HAS_NO_MEMBER = re.compile("Module 'numpy(?:\..+)?' has no '.+' member")
SCIPY_HAS_NO_MEMBER = re.compile("Module 'scipy(?:\..+)?' has no '.+' member")
SCIPY_HAS_NO_MEMBER2 = re.compile("No name '.+' in module 'scipy(?:\..+)?'")
NIPY_HAS_NO_MEMBER = re.compile("Module 'nipy(?:\..+)?' has no '.+' member")
SK_ATTR_DEFINED_OUTSIDE_INIT = re.compile("Attribute '.+_' defined outside __init__")
REL_IMPORT_SHOULD_BE = re.compile("Relative import '.+', should be '.+")
REDEFINING_NAME_FROM_OUTER_SCOPE = re.compile("Redefining name '.+' from outer scope")
if __name__ == "__main__":
basename = os.path.basename(sys.argv[1])
for line in Popen(['epylint', sys.argv[1], '--disable=C,R,I' # filter thesew arnings
], stdout=PIPE, stderr=STDOUT, universal_newlines=True).stdout:
if line.startswith("***********"):
continue
elif line.startswith("No config file found,"):
continue
elif "anomalous-backslash-in-string," in line:
continue
if NUMPY_HAS_NO_MEMBER.search(line):
continue
if SCIPY_HAS_NO_MEMBER.search(line):
continue
if SCIPY_HAS_NO_MEMBER2.search(line):
continue
if "Used * or ** magic" in line:
continue
if "No module named" in line and "_flymake" in line:
continue
if SK_ATTR_DEFINED_OUTSIDE_INIT.search(line):
continue
if "Access to a protected member" in line:
continue
if REL_IMPORT_SHOULD_BE.search(line):
continue
if REDEFINING_NAME_FROM_OUTER_SCOPE.search(line):
continue
if NIPY_HAS_NO_MEMBER.search(line):
continue
# XXX extend by adding more handles for false-positives here
else:
print line,
This script simply runs epylint, and then scrapes its output to filter out false-positive warnings and errors. You can extend it by added more elif cases.
N.B.: If this applies to you, then you'll want to modify your pychechers.sh so it likes like this
#!/bin/bash
epylint.py "$1" 2>/dev/null
pyflakes "$1"
pep8 --ignore=E221,E701,E202 --repeat "$1"
true
(Of course, you have to make epylint.py executable first.)
Here is a link to my .emacs https://github.com/dohmatob/mydotemacs.
On
I had to add this at the top of any file where I use NumPy a lot.
# To ignore numpy errors:
# pylint: disable=E1101
Just in case someone in eclipse is having trouble with Pydev and pylint...
On
This is the pseudo-solution I have come up with for this problem.
#pylint: disable=no-name-in-module
from numpy import array as np_array, transpose as np_transpose, \
linspace as np_linspace, zeros as np_zeros
from numpy.random import uniform as random_uniform
#pylint: enable=no-name-in-module
Then, in your code, instead of calling NumPy functions as np.array and np.zeros and so on, you would write np_array, np_zeros, etc.
Advantages of this approach vs. other approaches suggested in other answers:
The clear disadvantage is that you have to explicitly import every NumPy function you use.
The approach could be elaborated on further.
You could define your own module, call it say, numpy_importer as follows
""" module: numpy_importer.py
explicitely import numpy functions while avoiding Pylint errors
"""
#pylint: disable=unused-import
#pylint: disable=no-name-in-module
from numpy import array, transpose, zeros #add all things you need
from numpy.random import uniform as random_uniform
#pylint: enable=no-name-in-module
Then, your application code could import this module only (instead of NumPy) as
import numpy_importer as np
and use the names as usual: np.zeros, np.array etc.
The advantage of this is that you will have a single module in which all NumPy related imports are done once and for all, and then you import it with that single line, wherever you want. Still you have to be careful that numpy_importer does not import names that don’t exist in NumPy as those errors won't be caught by Pylint.
On
In recent versions of Pylint you can add --extension-pkg-whitelist=numpy to your Pylint command.
They had fixed this problem in an earlier version in an unsafe way. Now if you want them to look more carefully at a package outside of the standard library, you must explicitly whitelist it. See here.
On
If you don't want to add more configuration, please add this code to your configuration file, instead of 'whitelist'.
{
"python.linting.pylintArgs": ["--generate-members"],
}
It's an old bug with generated-members. If you use another name than numpy, like np or foo, then you must add it in the Pylint configuration (space or comma-separated - no matter), because Pylint doesn't recognize that. So it should look like this:
[pylint]
generated-members=numpy.*,np.*,foo.*
It even throws a full path in no-member error, but the expression needs to be exact. It's an old bug and seems to be fixed soon. Check Issue #2498 in logilab/pylint.
On
For ignoring all the errors generated by numpy.core‘s attributes, we can now use:
$ pylint a.py --generated-members=numpy.*
As another solution, add this option to ~/.pylintrc or /etc/pylintrc file:
[TYPECHECK]
# List of members which are set dynamically and missed by pylint inference
# system, and so shouldn't trigger E1101 when accessed. Python regular
# expressions are accepted.
generated-members=numpy.*
This feature was introduced in PyLint 1.6.0. It should be noted that code snippet from original question passed linting with this version even without any additional settings. However, this is useful in more complex cases.
On
This has finally been resolved in Pylint 1.8.2. It works out of the box, and pylintrc tweaks aren't needed!
On
In extension to j_hougs answer, you can now add the modules in question to this line in .pylintrc, which is already prepared empty on generation:
extension-pkg-whitelist=numpy
You can generate a sample .pylintrc by doing:
pylint --generate-rcfile > .pylintrc
And then edit the mentioned line.
On
I'm not sure if this is a solution, but in Visual Studio Code once I wrote explicitly in my user settings to enable Pylint, all modules were recognized.
{
"python.linting.pep8Enabled": true,
"python.linting.pylintEnabled": true
}
A little bit of copy paste from the previous answer to summarize what is working (at least for me: Debian 8 (Jessie))
In some older version of Pylint there was a problem preventing it working with NumPy (and other similar packages).
Now that problem has been solved, but external C packages (Python interfaces to C code -like NumPy-) are disabled by default for security reasons.
You can create a white list, to allow Pylint to use them in the file ~/.pylintrc.
Basic command to run:
# ONLY if you do not already have a .pylintrc file in your home
$ pylint --generate-rcfile > .pylintrc
Then open the file and add the packages you want after extension-pkg-whitelist= separated by comma. You can have the same behavior using the option --extension-pkg-whitelist=numpy from the command line.
If you ignore some packages in the [TYPECHECK] section that means that Pylint will never show errors related to those packages. In practice, Pylint will not tell you anything about those packages.
On
If using Visual Studio Code with Don Jayamanne's excellent Python extension, add a user setting to whitelist NumPy:
{
// Whitelist NumPy to remove lint errors
"python.linting.pylintArgs": [
"--extension-pkg-whitelist=numpy"
]
}
Lately (since something changed in Spyder or Pylint or ?), I have been getting E1101 errors ("no member") from Spyder's static code analysis on astropy.constants symbols. I don't have any idea why.
My simplistic solution for all users on a Linux or Unix system (Mac is probably similar) is to create an /etc/pylintrc file as follows:
[TYPECHECK]
ignored-modules=astropy.constants
Of course, this could, instead, be put in a personal $HOME/.pylintrc file. And, I could have updated an existing file.
Probably, it's confused with NumPy's abstruse method of methods import. Namely,
zerosis in factnumpy.core.multiarray.zeros, imported in NumPy with the statementin turn imported with
and in numeric you'll find
I guess I would be confused in place of Pylint!
See this bug for the Pylint side of view.