Mailman 3 March 2014 - code-quality

Using a linter on introduced code
by Mihai Bivol 28 Mar '14

28 Mar '14

Hello, I am working on a tool that integrates pylint with github pull requests[1]. 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. Thanks, Mihai [1] https://github.com/mihaibivol/pylinthub

3 2

[ANN] pep8 released, version 1.5
by Florent 26 Mar '14

26 Mar '14

Good morning, I'm pleased to announce the release of pep8 version 1.5. There are many changes in this version, including new and improved checkers. http://pep8.readthedocs.org/en/latest/developer.html#changes The list of error codes was updated accordingly: http://pep8.readthedocs.org/en/latest/intro.html#error-codes Thank you to everyone which posted feedback or pull requests on the tracker. To the developers, I wish this tool will continue to help you writing readable code ;-) -- Florent

1 0

Possible bug: False negative for W0613 on function member '__exit__'
by Andreas Maier 24 Mar '14

24 Mar '14

Hi, the following file misses to produce W0613 (unused argument) for the three exc_* arguments of member function __exit__(): class MyContextManager(object): """dummy docstring""" def __enter__(self): pass def __exit__(self, exc_type, exc_val, exc_tb): return False def func1(self, exc_type, exc_val, exc_tb): """dummy docstring""" return False def __func2__(self, exc_type, exc_val, exc_tb): return False 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. Versions: pylint 1.1.0, 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. Regards Andy

2 1

[ANN] Pyflakes 0.8 released
by Florent 24 Mar '14

24 Mar '14

Hello, Pyflakes 0.8 was released with some improvements. It officially supports Python 3.4 https://launchpad.net/pyflakes/+milestone/0.8 https://pypi.python.org/pypi/pyflakes In this version, the validation of the doctests is no longer active in the default configuration. The PYFLAKES_DOCTEST environment variable is used to activate them (https://bugs.launchpad.net/bugs/1223150). A new checker is added to catch return with arguments inside a generator (Python <= 3.2). The other changes are mostly bug fixes, -- Florent

1 0

Making git and pylint interact
by Anne Mulhern 19 Mar '14

19 Mar '14

Hi! 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 have introduced. (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. Thanks! - mulhern

4 4

False positive for E1101 on function member 'func_name'
by Andreas Maier 18 Mar '14

18 Mar '14

Hi again, I am using pylint 1.1.0 for Python 2.6 code. The following code: def myfunc(): 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? http://www.logilab.org/blogentry/78354 Kind Regards, Andy

2 1

False negative for pylint E0203 when using += operator?
by Andreas Maier 18 Mar '14

18 Mar '14

Hi, 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: class MyClass1(object): def __init__(self): 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: class MyClass2(object): def __init__(self): self.first += 5 # Correctly raises E1101: # Instance of 'MyClass2' has no # 'first' member Also just for comparison, here is code that correctly raises E0203: class MyClass3(object): def __init__(self): 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? Kind Regards, Andy

2 3