[code-quality] This seems like a good warning candidate...

2014-12-08 Thread Skip Montanaro
I just bumped into a bug, reusing the same loop variable in two nested for loops. Here's an example: def f(x): for i in range(x): for i in [1, 2, 3]: print i Neither pylint nor flake8 warned about this problematic usage. Had i or x shadowed a global of the same name, pylin

Re: [code-quality] This seems like a good warning candidate...

2014-12-08 Thread Ian Cordasco
On Dec 8, 2014 12:17 PM, "Skip Montanaro" wrote: > > I just bumped into a bug, reusing the same loop variable in two nested for loops. Here's an example: > > def f(x): > for i in range(x): > for i in [1, 2, 3]: > print i > > Neither pylint nor flake8 warned about this probl

Re: [code-quality] This seems like a good warning candidate...

2014-12-08 Thread Phil Frost
On Mon, Dec 8, 2014 at 1:24 PM, Ian Cordasco wrote: > > On Dec 8, 2014 12:17 PM, "Skip Montanaro" > wrote: > > > > Using the same variable in nested loops within the same function seems > at least as serious as a shadowed global (or builtin) name. > > I agree. I think this belongs in PyFlakes (a

Re: [code-quality] This seems like a good warning candidate...

2014-12-08 Thread Skip Montanaro
On Mon, Dec 8, 2014 at 1:32 PM, Phil Frost wrote: > Maybe. As a matter of principle, Pyflakes should only emit a warning for > things that it is sure is an error. The avoidance of false positives is a noble goal, but given the dynamic nature of Python, I'm happy to put up with a few if it means

Re: [code-quality] This seems like a good warning candidate...

2014-12-08 Thread Ian Cordasco
On Mon, Dec 8, 2014 at 2:07 PM, Skip Montanaro wrote: > > On Mon, Dec 8, 2014 at 1:32 PM, Phil Frost wrote: >> >> Maybe. As a matter of principle, Pyflakes should only emit a warning for >> things that it is sure is an error. > > > The avoidance of false positives is a noble goal, but given the d

[code-quality] The union of all tools

2014-12-08 Thread Skip Montanaro
Thinking about the discussion I (inadvertently) started about what sorts of issues should cause tools like pylint and pyflakes to emit messages, got me thinking about how I try to use these tools. I don't know what the current suite of all available static checking tools is, but let me just assume

Re: [code-quality] The union of all tools

2014-12-08 Thread Carl Crowder
Hi Skip, This kind of argument was on my mind a little when I made prospector (https://github.com/landscapeio/prospector) although probably from a different angle. There are many tools out there and using them all means you can get the maximal coverage of all concepts, with some overlap. Each tool

Re: [code-quality] This seems like a good warning candidate...

2014-12-08 Thread Phil Frost
On Mon, Dec 8, 2014 at 3:21 PM, Ian Cordasco wrote: > I'm not sure in what case code like what Skip shared wouldn't result > in an error: > > for i in range(1, 10): > for i in ['foo', 'frob', 'bob', 'bogus', 'smogus']: > do_stuff(i) > do_other_stuff(i) > A slight

Re: [code-quality] This seems like a good warning candidate...

2014-12-08 Thread Ian Cordasco
On Mon, Dec 8, 2014 at 3:44 PM, Phil Frost wrote: > On Mon, Dec 8, 2014 at 3:21 PM, Ian Cordasco > wrote: >> >> I'm not sure in what case code like what Skip shared wouldn't result >> in an error: >> >> for i in range(1, 10): >> for i in ['foo', 'frob', 'bob', 'bogus', 'smogus']: >>

Re: [code-quality] Time cost for pylint analyses?

2014-12-08 Thread Anne Mulhern
I was thinking by checker...but now that you point it out I realize that by module being checked would be interesting, too. - mulhern - Original Message - > From: "Torsten Marek" > To: "Anne Mulhern" > Cc: "code-quality" > Sent: Sunday, December 7, 2014 4:51:01 AM > Subject: Re: [code-