Yeah, I don't agree with all of pylint's suggestions. We'd probably want to
run it at "warning", since it flags some issues that "error" ignores. I had a
patch series that cleaned up the warnings, but I never quite completed it.
Ben, if it's useful, I can dust it off. However, since you're p
Sounds good, they say to use pychecker. I wonder if we should prefer
that over pylint?
Ethan
On Wed, Aug 24, 2011 at 12:15, Ben Pfaff wrote:
> I've been trying to following Google's Python style guide recently.
> Some work will be needed to adapt older code to its conventions.
>
> On Wed, Aug 2
I've been trying to following Google's Python style guide recently.
Some work will be needed to adapt older code to its conventions.
On Wed, Aug 24, 2011 at 12:13:47PM -0700, Ethan Jackson wrote:
> I think the first step would actually be deciding on a python style
> for OVS. pylint can be IMO ex
I think the first step would actually be deciding on a python style
for OVS. pylint can be IMO extremely draconian on certain issues. I
personally have a configuration file which disables quite a few of
it's less reasonable checks. I wonder if we should publish something
like this.
Ethan
On We
I'm becoming a big fan of running checks automatically on every build,
as we do with "sparse" on C code when C=1 is provided on the command
line. Probably we'd need to first fix all the existing pylint
problems though.
On Tue, Aug 23, 2011 at 11:57:42PM -0700, Justin Pettit wrote:
> pylint will c
pylint will complain about some of these things. It would be good to kick it
off, when available, when builds are run (or at least on a "make check"). I've
had it on my to-do list for a while, but haven't gotten around to it...
--Justin
On Aug 23, 2011, at 2:05 PM, Ben Pfaff wrote:
> 'tuple
