Mailman 3 June 2015 - code-quality

Adding python function arguments related customized rule in pylint
by Ahirnish Pareek Aug. 31, 2015

Aug. 31, 2015

Hi all, I want to add a customized check to my pylintrc file to check and report cases whenever I define a function in a python file like this: def foo( var1, name1=value, *args ): The problem that I want to deal with is that we should not have keyword arguments( *name1* ) before positional arguments( **args* ). Although the function can still be called by passing *name1* as positional argument but there would be no way to not specify *name1* but specify **args*. How can I add this check to pylintrc file? Thanks in advance! -- Regards, Ahirnish

3 13

pep8 vs. flake8 incompatibility ...
by Peter Danecek June 30, 2015

June 30, 2015

Dear all, I am writing this mail, after I was directed to it in [1]. I note that the latest released versions of pep8 and flake8 are not compatible. This situation now persists for several month. For the point of view of a project providing software packaging this is very unsatisfying. In particular, I am referring to Macports here [2]. Such project usually rely on the assumption that the latest released version tend to provide the best quality and user experience of a given software package, and if this should not be the case in one specific moment in time that problems are resolved timely. In the case of pep8 vs. flake8, flake8 imposes constraints on the versions of dependencies. While lower bounds are perfectly fine, the upper bounds are problematic, because a perfectly working and well tested port would break by construction at any time later, when one of its dependencies is updated. I of cause understand the problems involved with parallel developments, but I would argue that one major goal of any project should be to remain compatible with the most recent versions of its dependency when ever possible or to release once major issues are resolved. In the concrete case, it looks like the relevant issue [3], which causes the version constraint on pep8 (>=1.5.7,!=1.6.0,!=1.6.1,!=1.6.2) was actually resolved in [4] already some time ago, but this commit actually not released yet. On the other hand, constraints on mccabe (>=0.2.1,<0.4) & pyflakes (>=0.8.1,<0.9) are not founded on issues with concretely released software [1], but only hypothetical show-stoppers once these versions are effectively released [5]. I'd argue, such constraints shouldn't be around after all, but introduces only after test failure show evidence of any problem. Anyway, if develops want to insist on them [1], these should be relaxed timely after the release the relevant software. For pyflakes the release of version 0.9.0 dates back to 2015-05-31 [6], the release was acknowledged pretty timely in [7] and fixed in [8], but the change was no release thereafter yet. So my question is now when this issues with conflicting versions, can be expected to be solved upstream. This is of particular relevance to understand if and how to solve the downstream issue in Macports [2], and if we need to foresee for any interim solutions. Thank you very much! ~petr --- [1] https://gitlab.com/pycqa/flake8/issues/68 [2] https://trac.macports.org/ticket/47429 [3] https://gitlab.com/pycqa/flake8/issues/35 [4] https://github.com/jcrocholl/pep8/commit/435d1cbf995a659a82d1d4b42d25e34595… [5] https://trac.macports.org/ticket/47429#comment:4 [6] https://pypi.python.org/pypi/pyflakes/0.9.0 [7] https://gitlab.com/pycqa/flake8/issues/61 [8] https://gitlab.com/pycqa/flake8/commit/f2b0bb52e5dc94da2d0dbdbbe655956228bf…

3 3

Pylint Werkzeug plugin
by Joe Schafer June 27, 2015

June 27, 2015

Hi all, I'm trying to extend pylint to recognize Werkzeug's import trickery. Werkzeug uses a variable called `all_by_module` in https://github.com/mitsuhiko/werkzeug/blob/master/werkzeug/__init__.py to lazily load modules. Pylint doesn't recognize this scheme and flags statements like: from werkzeug import secure_filename My attempt to fix the problem is at https://github.com/jschaf/pylint-werkzeug/blob/master/pylint_werkzeug/__ini… I don't think I'm following an optimal path to success. Basically, I'm trying to recreate Python's import logic and then generate an AST with astroid. It's not going well. The current solution recurses endlessly, since creating the AST seems to trigger the pylint transform plugin. I'm looking for simpler or more robust alternatives to my current approach with imports. My problem seems somewhat related to the issue about changing flask.ext imports at https://bitbucket.org/logilab/astroid/issue/10/ Do you have any suggestions? Thanks, Joe Schafer

2 2

Spurious unused variable messages
by Skip Montanaro June 10, 2015

June 10, 2015

Code like this: import os import tempfile def func(): (fd, tmpfile) = tempfile.mkstemp(dir="/tmp") os.close(fd) print "{tmpfile}".format(**locals()) generates an unused variable warning for tmpfile, even though it's referenced in the string in the print statement. The string module has a Formatter class (since 2.6, apparently) which knows how to tear such format strings apart: >>> for elt in fmt.parse("{} {tmpfile} {1} {0:.3f}"): ... print elt ... ('', '', '', None) (' ', 'tmpfile', '', None) (' ', '1', '', None) (' ', '0', '.3f', None) I'm only now getting comfortable with the new string formatting stuff, but it seems to me that the most common use case will be to call the format method of a string literal (so this sort of usage should be fairly easy to detect). I don't think it should be terribly difficult to intersect the names coming out of Formatter.parse with the otherwise unused local variables, but I am completely unfamiliar with pylint's node traversal handlers (all the visit_* methods in variables.py). Can someone point me to some documentation for how this works, and what visit_* methods I can define? Thanks, Skip Montanaro

3 3

pylint crashes with RuntimeError: maximum recursion depth exceeded
by anatoly techtonik June 8, 2015

June 8, 2015

Hi, pylint crashes with whitespace and linefeeds checks. https://travis-ci.org/spyder-ide/spyder/jobs/65808371 I am not sure where it failed, and why it didn't return with error status -1. Is it possible to fix return code and show the name of file that caused the recursion? -- anatoly t.

3 3

Test for checking linefeeds
by anatoly techtonik June 4, 2015

June 4, 2015

Hi, I don't want to reinvent to bicycle (even though it is easy), so is there a support for checking linefeeds in any of the existing linter tools? The two checks in particular are interesting: 1. test that files don't have mixed linefeeeds 2. test that files comply with project linefeed style (LF in particular) This is needed for Travis checks, but I also want to run it standalone on Windows, so grep won't work. https://github.com/spyder-ide/spyder/issues/2424 Thanks. -- anatoly t.

2 8

New pytest plugin: pytest-mccabe
by Florian Bruhin June 2, 2015

June 2, 2015

Hi, (first of all, sorry for the cross-posting, but I can't decide on which list this belongs - at least I resisted sending it to the TIP list too :P) I recently started switching from flake8[1] to pytest-pep8[2] and pytest-flakes[3], but missed a way to run the mccabe[4] code complexity checker. So I wrote my first pytest plugin to integrate that with pytest: https://github.com/The-Compiler/pytest-mccabe Any feedback is welcome! I plan to write some more tests (for the config wildcards mainly) and run pylint/pyflakes/pep8 over it, and then I'll release v0.1 on PyPI. Thanks to: - Florian Schulze for pytest-flakes, on which the code is based. - Ned Batchelder for the original McCabe script. - Florent Xicluna for mccabe on PyPI. Florian [1] https://pypi.python.org/pypi/flake8 [2] https://pypi.python.org/pypi/pytest-pep8 [3] https://pypi.python.org/pypi/pytest-flakes [4] https://pypi.python.org/pypi/mccabe -- http://www.the-compiler.org | me(a)the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/

2 3