Originally reported by: Anonymous
I'm using pylint as part of an automated commit hook in git to check if any file that was changed is non-conformant. My git-hook looks something like:
#!bash
pylint --rcfile=my_pylint_config_file.cfg --reports=no ${PY_FILES_CHANGED[@]} 2>&1
Here, the bash array ${PY_FILES_CHANGED} is populated with the filenames of python files based on the files in the current commit. Today I ran into a strange error. My commit consisted of 2 files in the same directory (package) -- though I'm not sure if pylint cares about that.
#!python
$ pylint --reports=no package/foo.py package/bar.py
************* Module package.bar
C: 83, 4: Invalid attribute name "id" (invalid-name)
************* Module package.foo
R: 18, 0: Too many instance attributes (8/7) (too-many-instance-attributes)
$
$ pylint --reports=no package/bar.py package/foo.py
$
Is this expected behavior?
_Original comment by_ Claudiu Popa (BitBucket: PCManticore, GitHub: @PCManticore):
No, this is not expected, it's probably a bug. Could you provide your config file and some files which reproduces the issue for you? I tried with some dummy files, but I always get the same output.
_Original comment by_ Matt Gilson (BitBucket: mgilson1):
I'm trying to reproduce this one simply (outside of my source tree), but I'm having a bit of trouble. It seems that there's something going on with my packages and subpackages in our project. I'll keep trying to distill it down to a minimal amount of code that I can pass on. (I unfortunately can't post my actual code at the moment as it is proprietary).
If I can't distill it, I guess you'll have to close this one as "Not Reproducible", but maybe another use will find this in a google search with a code sample that can reproduce this one.
_Original comment by_ Matt Gilson (BitBucket: mgilson1):
To reproduce, unpack the tarball, then:
#!bash
cd /path/to/unpacked/tarball/pylint-bug2
pylint --report=no --rcfile=pylint_config services/email/{models,gmail}.py
pylint --report=no --rcfile=pylint_config services/email/{gmail,models}.py
_Original comment by_ Matt Gilson (BitBucket: mgilson1):
And if it matters, here's my pylint version/build info:
#!bash
$ pylint --version
No config file found, using default configuration
pylint 1.4.4,
astroid 1.3.6, common 1.0.1
Python 2.7.6 (default, Sep 9 2014, 15:04:36)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.39)]
The issue is still present. I am able to reproduce it using the files in the attached archive (mymodule.zip).
Steps to reproduce:
unzip mymodule.zipcd mymodulepylint mybase.py override.pyNo config file found, using default configuration
************* Module mymodule.mybase
C: 5, 0: Missing class docstring (missing-docstring)
R: 5, 0: Too few public methods (1/2) (too-few-public-methods)
************* Module mymodule.override
C: 5, 0: Missing function docstring (missing-docstring)
C: 6, 4: Black listed name "foo" (blacklisted-name)
------------------------------------------------------------------
Your code has been rated at 4.29/10 (previous run: 4.29/10, +0.00)
pylint override.py mybase.pyNo config file found, using default configuration
************* Module mymodule.override
C: 5, 0: Missing function docstring (missing-docstring)
C: 6, 4: Black listed name "foo" (blacklisted-name)
C: 7, 4: Attribute name "myInvalidName" doesn't conform to snake_case naming style (invalid-name)
************* Module mymodule.mybase
C: 5, 0: Missing class docstring (missing-docstring)
R: 5, 0: Too few public methods (1/2) (too-few-public-methods)
------------------------------------------------------------------
Your code has been rated at 2.86/10 (previous run: 2.86/10, +0.00)
Expected behaviour:
Identical output in steps 4. anf 5., as they only differ in the file order. Notice the extra Attribute name "myInvalidName" doesn't conform to snake_case naming style (invalid-name).
Pylint version:
pylint --version
No config file found, using default configuration
pylint 1.8.1,
astroid 1.6.0
Python 3.5.2 (default, Nov 23 2017, 16:37:01)
[GCC 5.4.0 20160609]
I've observed this to happen only if imports are using the import mymodule.<file> style, not when they use import <file> directly. Note that thirdparty.py demonstrates a third-party module in my case, which doesn't conform to the preferred coding style, which is where the invalid-name comes from. I was able to reproduce it on a more-recent pylint/python as well in docker:
pylint 1.8.4,
astroid 1.6.3
Python 3.6.5 (default, Mar 31 2018, 01:15:58)
[GCC 4.9.2]
I have also seen this with the Too many instance attributes error, but I don't have a good small test-case for that.
Have the same issue.