I am working on a tool that integrates pylint with github pull
requests. My goal is to make the linting process as less disruptive
as possible and help devs fix issues in their code before submitting
it to review. I saw in another thread that some of you already have
some experience using a linter on introduced code. Before continuing
working on my approach I am curious to see how other approaches worked
and how others introduced this in their team's workflow.
the following file misses to produce W0613 (unused argument) for the
three exc_* arguments of member function __exit__():
def __exit__(self, exc_type, exc_val, exc_tb):
def func1(self, exc_type, exc_val, exc_tb):
def __func2__(self, exc_type, exc_val, exc_tb):
func1() and __func__2() which have just been added to see how pylint
behaves for them, correctly produce W0613 for all three exc_* arguments.
I am not aware of any pylint option that influences the specific
behavior of pylint w.r.t. __exit__() and unused arguments.
My pylint config file is the default generated one, except for a few
changes for metrics related messages, and one change in naming
conventions for modules.
astroid 1.0.1, common 0.61.0
Python 2.6.8 (unknown, Sep 27 2013, 16:11:04)
[GCC 4.3.4 [gcc-4_3-branch revision 152973]]
When searching the issues database for 'W0613' and '__exit__' I did not
find any existing bugs on this behavior.
Please let me know whether this should be considered a bug and whether
you want me to open an issue for it.
This is a question about making your favorite VCS and pylint interact.
The idea is that sometimes there's a project and you're running pylint on it, but you want to distinguish among two kinds of errors:
1) Errors introduced by the last few commits.
2) Errors that have been around forever and that are not the committers responsibility to fix.
If you have a lot of errors of type (2) you don't want the committer to have to wade through them looking for any errors they might
(Of course, there is a very hard working person in the background who is constantly working on addressing the many errors of type (2)).
So, it is easy to automate running pylint on a tree that includes the last few commits (as specified by the user) and also
on a tree that is missing the last few commits.
The problem is diffing the results from running pylint on these two different trees.
I see that the pylint results are dumped in pickle format into a pylint.d directory. Presumably it is from that info that
the textual reports are extracted and displayed, though I am not certain.
I can see that something similar has been proposed before: http://www.logilab.org/ticket/20386.
However, the difference is that I assume two pylint.d directories, one for each source tree, and I'm interested in comparing them, somehow.
It is not sufficient to do an exact compare, as line numbers and so forth may be changed.
I'ld welcome suggestions or if anybody has knowledge of any existing utility that does this that would be great.
I am using pylint 1.1.0 for Python 2.6 code.
The following code:
print myfunc.func_name # Incorrectly raises E1101
print myfunc.__name__ # Correctly passes
causes this pylint error to be raised:
E1101: Function 'myfunc' has no 'func_name' member
Python supports the func_name member in addition to __name__ since
Python 2.1, see http://docs.python.org/2.7/library/inspect.html
Is this pylint behavior a bug or is it currently unavoidable because
it is related to dynamic code as described here?
I am using PyLint 1.1.0 with Python 2.6, and found that the following
code does not raise E0203 "Access to member '%s' before its
definition line %s", as it should:
self.first += 5 # Does not raise E0203 as it should
self.first = 0
Just for comparison, when omitting the straight assignment on the
second line of the method, message E1101 is raised, so the instance
attribute is (correctly) recognized to be read before the addition:
self.first += 5 # Correctly raises E1101:
# Instance of 'MyClass2' has no
# 'first' member
Also just for comparison, here is code that correctly raises E0203:
self.first = self.sec # Correctly raises E0203:
# Access to member 'sec' before
# its definition line <N>
self.sec = 0
When researching this behavior, I seem to have found a notice somewhere
stating that the += operator is incorrectly not recognized by PyLint
as reading the value first, but I could not find the notice again,
nor could I find an entry for this issue in the (new) PyLint issues
list at https://bitbucket.org/logilab/pylint/issues/
My questions are:
* Should this be considered a bug in PyLint?
* If so, has this been reported already?