From andreas.r.maier at gmx.de  Mon Mar 17 19:40:58 2014
From: andreas.r.maier at gmx.de (Andreas Maier)
Date: Mon, 17 Mar 2014 19:40:58 +0100
Subject: [code-quality] False negative for pylint E0203 when using +=
	operator?
In-Reply-To: <532740ED.7030703@gmx.de>
References: <532740ED.7030703@gmx.de>
Message-ID: <532741BA.106@gmx.de>

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



From sylvain.thenault at logilab.fr  Tue Mar 18 09:32:21 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Tue, 18 Mar 2014 09:32:21 +0100
Subject: [code-quality] False negative for pylint E0203 when using +=
 operator?
In-Reply-To: <532741BA.106@gmx.de>
References: <532740ED.7030703@gmx.de>
 <532741BA.106@gmx.de>
Message-ID: <20140318083221.GA2601@logilab.fr>

On 17 mars 19:40, Andreas Maier wrote:
> Hi,

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?

IIRC it has indeed already been mentioned but I'm not sure there is a proper
issue for it. And your report is nice, so please put it as an issue in bitbucket
an mark it as important.

Thx
-- 
Sylvain Th?nault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, M?th. Agiles: http://www.logilab.fr/formations
D?veloppement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

From andreas.r.maier at gmx.de  Tue Mar 18 10:18:51 2014
From: andreas.r.maier at gmx.de (Andreas Maier)
Date: Tue, 18 Mar 2014 10:18:51 +0100
Subject: [code-quality] False negative for pylint E0203 when using +=
	operator?
In-Reply-To: <20140318083221.GA2601@logilab.fr>
References: <532740ED.7030703@gmx.de> <532741BA.106@gmx.de>
 <20140318083221.GA2601@logilab.fr>
Message-ID: <53280F7B.7080106@gmx.de>

Hello Sylvain,
Thanks for your quick response.

I have created Issue #164:
https://bitbucket.org/logilab/pylint/issue/164/

Andy

Am 18.03.2014 09:32, schrieb Sylvain Th?nault:
>
> IIRC it has indeed already been mentioned but I'm not sure there is a proper
> issue for it. And your report is nice, so please put it as an issue in bitbucket
> an mark it as important.
>


From sylvain.thenault at logilab.fr  Tue Mar 18 10:30:46 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Tue, 18 Mar 2014 10:30:46 +0100
Subject: [code-quality] False negative for pylint E0203 when using +=
 operator?
In-Reply-To: <53280F7B.7080106@gmx.de>
References: <532740ED.7030703@gmx.de> <532741BA.106@gmx.de>
 <20140318083221.GA2601@logilab.fr> <53280F7B.7080106@gmx.de>
Message-ID: <20140318093046.GD2601@logilab.fr>

On 18 mars 10:18, Andreas Maier wrote:
> Hello Sylvain,
> Thanks for your quick response.
> 
> I have created Issue #164:
> https://bitbucket.org/logilab/pylint/issue/164/

thanks ! I'm afraid the fix won't be so quick though ;)
-- 
Sylvain Th?nault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, M?th. Agiles: http://www.logilab.fr/formations
D?veloppement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

From andreas.r.maier at gmx.de  Tue Mar 18 10:31:22 2014
From: andreas.r.maier at gmx.de (Andreas Maier)
Date: Tue, 18 Mar 2014 10:31:22 +0100
Subject: [code-quality] False positive for E1101 on function member
	'func_name'
Message-ID: <5328126A.8040401@gmx.de>

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

From sylvain.thenault at logilab.fr  Tue Mar 18 10:47:57 2014
From: sylvain.thenault at logilab.fr (Sylvain =?utf-8?B?VGjDqW5hdWx0?=)
Date: Tue, 18 Mar 2014 10:47:57 +0100
Subject: [code-quality] False positive for E1101 on function member
 'func_name'
In-Reply-To: <5328126A.8040401@gmx.de>
References: <5328126A.8040401@gmx.de>
Message-ID: <20140318094757.GF2601@logilab.fr>

On 18 mars 10:31, Andreas Maier wrote:
> Hi again,

Hi,

> 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

This has been reported in
https://bitbucket.org/logilab/pylint/issue/139/no-member-false-positive-for-functions

It should actually be handled in astroid, or maybe in pylint-brain indeed, but
not in pylint itself.

-- 
Sylvain Th?nault, LOGILAB, Paris (01.45.32.03.12) - Toulouse (05.62.17.16.42)
Formations Python, Debian, M?th. Agiles: http://www.logilab.fr/formations
D?veloppement logiciel sur mesure:       http://www.logilab.fr/services
CubicWeb, the semantic web framework:    http://www.cubicweb.org

From amulhern at redhat.com  Tue Mar 18 23:27:58 2014
From: amulhern at redhat.com (Anne Mulhern)
Date: Tue, 18 Mar 2014 18:27:58 -0400 (EDT)
Subject: [code-quality] Making git and pylint interact
In-Reply-To: <1052584890.1103324.1395179677014.JavaMail.zimbra@redhat.com>
Message-ID: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>

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


From ned at nedbatchelder.com  Wed Mar 19 01:18:01 2014
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Tue, 18 Mar 2014 20:18:01 -0400
Subject: [code-quality] Making git and pylint interact
In-Reply-To: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>
References: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>
Message-ID: <5328E239.6050002@nedbatchelder.com>

On 3/18/14 6:27 PM, Anne Mulhern wrote:
> 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.
At edX, we wrote a tool called diff-cover that produces differential 
coverage reports, and also pylint and pep8 reports.  It lets the 
developer focus on the effect of the changes they are making, rather 
than on the entire working tree: https://github.com/edx/diff-cover

--Ned.
>
> Thanks!
>
> - mulhern
>
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality


From amulhern at redhat.com  Wed Mar 19 13:11:46 2014
From: amulhern at redhat.com (Anne Mulhern)
Date: Wed, 19 Mar 2014 08:11:46 -0400 (EDT)
Subject: [code-quality] Making git and pylint interact
In-Reply-To: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>
References: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>
Message-ID: <1973094558.1314370.1395231106600.JavaMail.zimbra@redhat.com>

Hi!

Thanks for your responses.

One thing I noticed is that the responses I got all took the same approach:

report only errors that are located on lines that have changed. I'll call
this the code diff approach.

What I was actually looking for was new errors introduced by the changes,
which I'll call the pylint diff approach.
For instance, if a use of a variable gets deleted by a change, a previous
assignment may become unused, and pylint would report the error at the
assignment line. This newly introduced error would be left out by the
code diff approach.

On the other hand, there's an argument that says that even if an error
is not created by a change, if it is on a line that you changed, you
should probably fix it.

So, I think the pylint diff and the code diff approach could complement
each other nicely.

So again, thanks to everybody who responded, but I'm not entirely satisfied yet,
and if anybody has anything further to add, I'm still interested.

- mulhern



From adi at roiban.ro  Wed Mar 19 13:19:04 2014
From: adi at roiban.ro (Adi Roiban)
Date: Wed, 19 Mar 2014 14:19:04 +0200
Subject: [code-quality] Making git and pylint interact
In-Reply-To: <1973094558.1314370.1395231106600.JavaMail.zimbra@redhat.com>
References: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>
 <1973094558.1314370.1395231106600.JavaMail.zimbra@redhat.com>
Message-ID: <CAFycZ9f_Ra+vUCNc5yiEmiO1oMEdECCZ9E2MNrsS9sL0nbVV=g@mail.gmail.com>

On 19 March 2014 14:11, Anne Mulhern <amulhern at redhat.com> wrote:
[snip]
> So again, thanks to everybody who responded, but I'm not entirely satisfied yet,
> and if anybody has anything further to add, I'm still interested.
>
> - mulhern

I heard that twisted's buildbot configuration is doing something like
this.. but is custom code.
For example trunk branch has a lot of pyflakes errors but buildbot
only look for newly introduced errors... not sure how.


-- 
Adi Roiban

From skip at pobox.com  Wed Mar 19 13:40:16 2014
From: skip at pobox.com (Skip Montanaro)
Date: Wed, 19 Mar 2014 07:40:16 -0500
Subject: [code-quality] Making git and pylint interact
In-Reply-To: <1973094558.1314370.1395231106600.JavaMail.zimbra@redhat.com>
References: <734691843.1114441.1395181678303.JavaMail.zimbra@redhat.com>
 <1973094558.1314370.1395231106600.JavaMail.zimbra@redhat.com>
Message-ID: <CANc-5UxOViszvqZ2kmxEUjrocqaBTOG7p-o2yNKWFuEFuWMhEA@mail.gmail.com>

> I'm not entirely satisfied yet,
> and if anybody has anything further to add, I'm still interested.

My thinking is that if the code differences don't tell you what
changes in pylint output are important, then maybe either

* pylint results should be stored under version control so you can diff them

or

* pylint should be run on both the reference checkin and the current
state of your code

In either case, you'd need to do a bit of a tricky dance when
messages. To avoid spurious diffs, you might have to substitute "NNN"
for your line numbers, compare, then restore the actual line numbers
in the messages you present to the user.

Skip

From florent.xicluna at gmail.com  Mon Mar 24 08:55:19 2014
From: florent.xicluna at gmail.com (Florent)
Date: Mon, 24 Mar 2014 08:55:19 +0100
Subject: [code-quality] [ANN] Pyflakes 0.8 released
Message-ID: <CAPFzasNbS7C8Jv3NkaH8ASdjqQ_iEOnbtS0cTNYOWSOiqsCLTg@mail.gmail.com>

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

From andreas.r.maier at gmx.de  Mon Mar 24 16:06:31 2014
From: andreas.r.maier at gmx.de (Andreas Maier)
Date: Mon, 24 Mar 2014 16:06:31 +0100
Subject: [code-quality] Possible bug: False negative for W0613 on function
	member '__exit__'
Message-ID: <533049F7.9060201@gmx.de>

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


From adi at roiban.ro  Mon Mar 24 16:19:00 2014
From: adi at roiban.ro (Adi Roiban)
Date: Mon, 24 Mar 2014 17:19:00 +0200
Subject: [code-quality] Possible bug: False negative for W0613 on
 function member '__exit__'
In-Reply-To: <533049F7.9060201@gmx.de>
References: <533049F7.9060201@gmx.de>
Message-ID: <CAFycZ9dhOF=x+-SCY2_V1SoW8UyEpX+R2iMLPvvYqiDype3K5w@mail.gmail.com>

On 24 March 2014 17:06, Andreas Maier <andreas.r.maier at gmx.de> wrote:
> Hi,
> the following file misses to produce W0613 (unused argument) for the three
> exc_* arguments of member function __exit__():

For me, this is a feature!

Python force you to define the __exit__ method with those arguments
and is not the user who defines method with extra / unused arguments.

In many cased I don't use the exit arguments and they I would have to
add fake references to those arguments to comply with pylint new
warnings.

-- 
Adi Roiban

From florent.xicluna at gmail.com  Wed Mar 26 12:06:11 2014
From: florent.xicluna at gmail.com (Florent)
Date: Wed, 26 Mar 2014 12:06:11 +0100
Subject: [code-quality] [ANN] pep8 released, version 1.5
Message-ID: <CAPFzasOMwcfgLqB+7h+q75z+8tz5JKr3JWRmPMOczX598qgCUw@mail.gmail.com>

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

From mm.bivol at gmail.com  Fri Mar 28 15:30:39 2014
From: mm.bivol at gmail.com (Mihai Bivol)
Date: Fri, 28 Mar 2014 16:30:39 +0200
Subject: [code-quality] Using a linter on introduced code
Message-ID: <CAJFc0PFyxEncg42Z2BocR9nbF3AmD6q187ybexFksVnLVE=O7w@mail.gmail.com>

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

From ned at nedbatchelder.com  Fri Mar 28 16:05:06 2014
From: ned at nedbatchelder.com (Ned Batchelder)
Date: Fri, 28 Mar 2014 11:05:06 -0400
Subject: [code-quality] Using a linter on introduced code
In-Reply-To: <CAJFc0PFyxEncg42Z2BocR9nbF3AmD6q187ybexFksVnLVE=O7w@mail.gmail.com>
References: <CAJFc0PFyxEncg42Z2BocR9nbF3AmD6q187ybexFksVnLVE=O7w@mail.gmail.com>
Message-ID: <53358FA2.7010500@nedbatchelder.com>


On 3/28/14 10:30 AM, Mihai Bivol wrote:
> 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.

We have a tool that does coverage and pylint measurement on github 
submissions: 
http://engineering.edx.org/2013/12/diff-cover-test-coverage-for-git-commits/ 
It's run automatically by our Jenkins CI server, and many developers run 
it locally to check on the work they are about to submit.

--Ned.
>
>
> Thanks,
> Mihai
>
> [1] https://github.com/mihaibivol/pylinthub
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality


From amulhern at redhat.com  Fri Mar 28 16:25:44 2014
From: amulhern at redhat.com (Anne Mulhern)
Date: Fri, 28 Mar 2014 11:25:44 -0400 (EDT)
Subject: [code-quality] Using a linter on introduced code
In-Reply-To: <53358FA2.7010500@nedbatchelder.com>
References: <CAJFc0PFyxEncg42Z2BocR9nbF3AmD6q187ybexFksVnLVE=O7w@mail.gmail.com>
 <53358FA2.7010500@nedbatchelder.com>
Message-ID: <2114979736.5487479.1396020344093.JavaMail.zimbra@redhat.com>





----- Original Message -----
> From: "Ned Batchelder" <ned at nedbatchelder.com>
> To: code-quality at python.org
> Sent: Friday, March 28, 2014 11:05:06 AM
> Subject: Re: [code-quality] Using a linter on introduced code
> 
> 
> On 3/28/14 10:30 AM, Mihai Bivol wrote:
> > 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.
> 
> We have a tool that does coverage and pylint measurement on github
> submissions:
> http://engineering.edx.org/2013/12/diff-cover-test-coverage-for-git-commits/
> It's run automatically by our Jenkins CI server, and many developers run
> it locally to check on the work they are about to submit.
> 
> --Ned.
> >
> >
> > Thanks,
> > Mihai
> >
> > [1] https://github.com/mihaibivol/pylinthub
> > _______________________________________________
> > code-quality mailing list
> > code-quality at python.org
> > https://mail.python.org/mailman/listinfo/code-quality
> 
> _______________________________________________
> code-quality mailing list
> code-quality at python.org
> https://mail.python.org/mailman/listinfo/code-quality
> 

It was not hard to write a little script to make use of
code-quality for my somewhat different scenario, i.e.,
developer has a bunch of commits stacked up and they're
interested in running code-quality on the changes that
comprise those commits before submitting for review.

The dead simple script here: https://github.com/dwlehman/blivet/blob/master/scripts/pylintcodediff
is kind of reckless with your working branch, but I expect to be pushing a few patches
for that in the very near future to make it a bit safer.

So far it is not a git-hook or anything like that,
it needs a bit of work before I'ld be willing to automate it.

- mulhern