Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #108275 > unrolled thread

pylint woes

Back to article view | Back to comp.lang.python

Contents

  pylint woes DFS <nospam@dfs.com> - 2016-05-07 12:51 -0400
    Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 03:01 +1000
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 21:16 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 11:36 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 22:15 -0400
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 12:50 +1000
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-10 18:36 -0400
                Re: pylint woes MRAB <python@mrabarnett.plus.com> - 2016-05-11 02:02 +0100
        Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 19:14 -0700
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 23:04 -0400
            Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 20:46 -0700
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 10:26 -0400
            Re: pylint woes Jussi Piitulainen <jussi.piitulainen@helsinki.fi> - 2016-05-08 08:50 +0300
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 10:25 -0400
                Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 00:36 +1000
                  Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 11:06 -0400
                    Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 08:15 -0700
                      Re: pylint woes Gregory Ewing <greg.ewing@canterbury.ac.nz> - 2016-05-09 13:17 +1200
                        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 12:18 +1000
                        Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 22:58 -0400
                    Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 01:15 +1000
                      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:06 -0400
                Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 08:11 -0700
                Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 01:51 +1000
                  Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:04 -0400
                    Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 13:09 +1000
        Re: pylint woes MRAB <python@mrabarnett.plus.com> - 2016-05-08 03:21 +0100
        Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-08 21:36 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:24 -0400
            Re: pylint woes Joel Goldstick <joel.goldstick@gmail.com> - 2016-05-08 17:39 -0400
            Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 13:46 +1000
    Re: pylint woes Michael Selik <michael.selik@gmail.com> - 2016-05-07 18:42 +0000
    Re: pylint woes Peter Pearson <pkpearson@nowhere.invalid> - 2016-05-07 18:43 +0000
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:05 -0400
    Re: pylint woes Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-07 11:52 -0700
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 23:38 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 13:56 +1000
        Re: pylint woes Peter Otten <__peter__@web.de> - 2016-05-08 16:19 +0200
    Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 12:21 -0700
    Re: pylint woes Stephen Hansen <me@ixokai.io> - 2016-05-07 12:23 -0700
    Re: pylint woes Terry Reedy <tjreedy@udel.edu> - 2016-05-07 15:40 -0400
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-07 23:28 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 13:51 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 00:40 -0400
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 14:55 +1000
        Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-07 20:55 -0700
        Re: pylint woes Ian Kelly <ian.g.kelly@gmail.com> - 2016-05-07 23:09 -0600
        Re: pylint woes Peter Otten <__peter__@web.de> - 2016-05-08 16:12 +0200
    Re: pylint woes Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-07 12:43 -0700
    Re: pylint woes Ray Cote <rgacote@appropriatesolutions.com> - 2016-05-07 15:52 -0400
    Re: pylint woes Christopher Reimer <christopher_reimer@icloud.com> - 2016-05-07 13:20 -0700
    Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 07:56 +1000
    Re: pylint woes Terry Reedy <tjreedy@udel.edu> - 2016-05-07 21:44 -0400
    Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-08 13:25 +1000
      Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 00:10 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 14:21 +1000
        Re: pylint woes "D'Arcy J.M. Cain" <darcy@VybeNetworks.com> - 2016-05-08 08:50 -0400
        Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-08 23:01 +1000
          Re: pylint woes Larry Hudson <orgnut@yahoo.com> - 2016-05-08 13:45 -0700
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 08:07 +1000
              Re: pylint woes Larry Hudson <orgnut@yahoo.com> - 2016-05-08 18:28 -0700
          Re: pylint woes Dan Sommers <dan@tombstonezero.net> - 2016-05-08 20:49 +0000
            Re: pylint woes Chris Angelico <rosuav@gmail.com> - 2016-05-09 08:10 +1000
        Re: pylint woes Steven D'Aprano <steve@pearwood.info> - 2016-05-09 03:25 +1000
          Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:16 -0400
            Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 14:38 -0700
              Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 17:46 -0400
                Re: pylint woes Stephen Hansen <me+python@ixokai.io> - 2016-05-08 15:05 -0700
                  Re: pylint woes DFS <nospam@dfs.com> - 2016-05-08 18:24 -0400

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#108290

On 5/7/2016 12:51 PM, DFS wrote:
> This more-anal-than-me program generated almost 2 warnings for every
> line of code in my program.  w t hey?

If you don't like it, why do you use it?

I suppose the answer is that it did find a few things to check.  You 
might be happier with pychecker, which is much less aggressive.  I 
believe will find the things you did fix.


>                                           DFS comments
> +-------------------------+------------+ -------------------------------
> |message id               |occurrences |
> +=========================+============+
> |mixed-indentation        |186         | I always use tab
> +-------------------------+------------+
> |invalid-name             |82          | every single variable name?!

I would need examples to comment.

> +-------------------------+------------+
> |trailing-whitespace      |59          | heh!

Any code editor should have a command to fix this.
IDLE: Format => strip trailing whitespace
Notepad++: Macro => trim trailing and save, Alt-Shift-S
others ...

> +-------------------------+------------+
> |no-member                |5           |
>
> "Module 'pyodbc' has no 'connect' member"   Yes it does.
> "Module 'pyodbc' has no 'Error' member"     Yes it does.
>
> Issue with pylint, or pyodbc?

Worth looking into.  Could be a bug somewhere. But I don't have pyodbc 
installed.

> +-------------------------+------------+
> |line-too-long            |5           | meh

For following the PEP guideline when patching CPython, this is helpful.

> +-------------------------+------------+
> |wrong-import-order       |4           | does it matter?

Consistency in imports ultimately makes easier reading.
Many idlelib files use this order: stdlib modules other than tkinter and 
idlelib (alphabetically); tkinter (tkinter first, then submodules); 
idlelib (alphabetically).  When I edit files, I sometimes reorder 
imports to conform.

> +-------------------------+------------+
> |missing-docstring        |4           | what's the difference between
>                                          a docstring and a # comment?

# Comments only appear in the source
'''Docstrings are copied to the compiled code object, are interactively 
accessible, and are used for help(ojb) output.'''


> +-------------------------+------------+
> |superfluous-parens       |3           | I like to surround 'or'
>                                          statments with parens

I would need examples to comment


> +-------------------------+------------+
> |bad-builtin              |2           | warning because I used filter?

If they are still doing this in the latest release, it is an arrogance 
and inconsistency bug on their part.  Disable this check.

> +-------------------------+------------+
> |missing-final-newline    |1           | I'm using Notepad++, with
>                                          EOL Conversion set to
>                                          'Windows Format'.

That says to replace final '\n' with '\r\n'.  It does not affect a 
missing final newline ;-)

                                            How or should I fix this?

Fix by hitting 'Enter' at the end of the last line.
Should you?  I think it a good habit.

> After fixes and disabling various warnings:
> "Your code has been rated at 8.37/10"

Being able to customize pylint by turning off warnings is its saving 
feature.

-- 
Terry Jan Reedy

[toc] | [prev] | [next] | [standalone]

#108327

On 5/7/2016 3:40 PM, Terry Reedy wrote:
> On 5/7/2016 12:51 PM, DFS wrote:
>> This more-anal-than-me program generated almost 2 warnings for every
>> line of code in my program.  w t hey?
>
> If you don't like it, why do you use it?


I've never used it before last night.  I was shocked at what it spewed 
back at me.



> I suppose the answer is that it did find a few things to check.  You
> might be happier with pychecker, which is much less aggressive.

I'll give it a shot.



> I believe will find the things you did fix.

I'm not parsing this statement.  You mean pychecker will find the same 
things pylint found, and that I fixed?

If it finds them after I fixed them... it's a magical program :)



                                             DFS comments
>> +-------------------------+------------+ -------------------------------
>> |message id               |occurrences |
>> +=========================+============+
>> |mixed-indentation        |186         | I always use tab
>> +-------------------------+------------+
>> |invalid-name             |82          | every single variable name?!
>
> I would need examples to comment.


Invalid constant name "cityzip" (invalid-name)
Invalid constant name "state" (invalid-name)
Invalid constant name "miles" (invalid-name)
Invalid constant name "store" (invalid-name)
Invalid variable name "rs" (invalid-name)



>> +-------------------------+------------+
>> |trailing-whitespace      |59          | heh!
>
> Any code editor should have a command to fix this.
> IDLE: Format => strip trailing whitespace
> Notepad++: Macro => trim trailing and save, Alt-Shift-S
> others ...

That did it.


>> +-------------------------+------------+
>> |no-member                |5           |
>>
>> "Module 'pyodbc' has no 'connect' member"   Yes it does.
>> "Module 'pyodbc' has no 'Error' member"     Yes it does.
>>
>> Issue with pylint, or pyodbc?
>
> Worth looking into.  Could be a bug somewhere. But I don't have pyodbc
> installed.
>
>> +-------------------------+------------+
>> |line-too-long            |5           | meh
>
> For following the PEP guideline when patching CPython, this is helpful.
>
>> +-------------------------+------------+
>> |wrong-import-order       |4           | does it matter?
>
> Consistency in imports ultimately makes easier reading.
> Many idlelib files use this order: stdlib modules other than tkinter and
> idlelib (alphabetically); tkinter (tkinter first, then submodules);
> idlelib (alphabetically).  When I edit files, I sometimes reorder
> imports to conform.


It complains 2x about this:

import os, sys, time, datetime
import pyodbc, sqlite3
import re, requests
from lxml import html


But I think there are some pylint bugs here:
-------------------------------------------------------------------------

standard import "import pyodbc, sqlite3" comes before "import pyodbc, 
sqlite3" (wrong-import-order)

   * complains that the line comes before itself?

-------------------------------------------------------------------------

standard import "import re, requests" comes before "import pyodbc, 
sqlite3" (wrong-import-order)

   * So I switched them, and then it complained about that:

standard import "import pyodbc, sqlite3" comes before "import re, 
requests" (wrong-import-order)

-------------------------------------------------------------------------

You can't win with pylint...

And, the author probably isn't a native English-speaker, since when he 
says 'comes before' I think he means 'should come before'.





>> +-------------------------+------------+
>> |missing-docstring        |4           | what's the difference between
>>                                          a docstring and a # comment?
>
> # Comments only appear in the source
> '''Docstrings are copied to the compiled code object, are interactively
> accessible, and are used for help(ojb) output.'''
>
>
>> +-------------------------+------------+
>> |superfluous-parens       |3           | I like to surround 'or'
>>                                          statments with parens
>
> I would need examples to comment


if ("Please choose a state" in str(matches)):
if (var == "val" or var2 == "val2"):


>> +-------------------------+------------+
>> |bad-builtin              |2           | warning because I used filter?
>
> If they are still doing this in the latest release, it is an arrogance
> and inconsistency bug on their part.  Disable this check.

$ pylint --version
No config file found, using default configuration
pylint 1.5.5,
astroid 1.4.5
Python 2.7.11 (v2.7.11:6d1b6a68f775, Dec  5 2015, 20:32:19) [MSC v.1500 
32 bit (Intel)]


It says "Used builtin function 'filter'. Using a list comprehension can 
be clearer. (bad-builtin)"



>> +-------------------------+------------+
>> |missing-final-newline    |1           | I'm using Notepad++, with
>>                                          EOL Conversion set to
>>                                          'Windows Format'.
>
> That says to replace final '\n' with '\r\n'.  It does not affect a
> missing final newline ;-)
>
>                                            How or should I fix this?
>
> Fix by hitting 'Enter' at the end of the last line.
> Should you?  I think it a good habit.

Done


>> After fixes and disabling various warnings:
>> "Your code has been rated at 8.37/10"
>
> Being able to customize pylint by turning off warnings is its saving
> feature.

Yes.  If I had to see 300-350 lines of output every time I wouldn't ever 
use it again.

Overall, I do like a majority of the things it suggested.

[toc] | [prev] | [next] | [standalone]

#108332

On Sun, May 8, 2016 at 1:28 PM, DFS <nospam@dfs.com> wrote:
> Invalid constant name "cityzip" (invalid-name)
> Invalid constant name "state" (invalid-name)
> Invalid constant name "miles" (invalid-name)
> Invalid constant name "store" (invalid-name)
> Invalid variable name "rs" (invalid-name)

... huh?? The first four seem to have been incorrectly detected as
constants. How are they used?

The last one is probably "too short". Or something.

> standard import "import re, requests" comes before "import pyodbc, sqlite3"
> (wrong-import-order)
>
>   * So I switched them, and then it complained about that:
>
> standard import "import pyodbc, sqlite3" comes before "import re, requests"
> (wrong-import-order)
>
> -------------------------------------------------------------------------
>
> You can't win with pylint...

Probably that means it got confused by the alphabetization - "pyodbc"
should come before "re" and "requests", but "sqlite3" should come
after. Either fix the first problem by splitting them onto separate
lines, or ignore this as a cascaded error.

My general principle is that things on one line should *belong* on one
line. So having "import re, requests" makes no sense, but I might have
something like "import os, sys" when the two modules are both used in
one single line of code and never again. Otherwise, splitting them out
is the easiest.


>>> +-------------------------+------------+
>>> |superfluous-parens       |3           | I like to surround 'or'
>>>                                          statments with parens
>>
>>
>> I would need examples to comment
>
>
>
> if ("Please choose a state" in str(matches)):
> if (var == "val" or var2 == "val2"):

Cut the parens. Easy!

> It says "Used builtin function 'filter'. Using a list comprehension can be
> clearer. (bad-builtin)"

Kill that message and keep using filter.

ChrisA

[toc] | [prev] | [next] | [standalone]

#108337

On 5/7/2016 11:51 PM, Chris Angelico wrote:
> On Sun, May 8, 2016 at 1:28 PM, DFS <nospam@dfs.com> wrote:
>> Invalid constant name "cityzip" (invalid-name)
>> Invalid constant name "state" (invalid-name)
>> Invalid constant name "miles" (invalid-name)
>> Invalid constant name "store" (invalid-name)
>> Invalid variable name "rs" (invalid-name)
>
> ... huh?? The first four seem to have been incorrectly detected as
> constants. How are they used?

The first four are set once and not changed.  Probably that's why it 
calls it a constant.




> The last one is probably "too short". Or something.

In this case, rs is a pyodbc row object.

rs = cursor.fetchone()



>> standard import "import re, requests" comes before "import pyodbc, sqlite3"
>> (wrong-import-order)
>>
>>   * So I switched them, and then it complained about that:
>>
>> standard import "import pyodbc, sqlite3" comes before "import re, requests"
>> (wrong-import-order)
>>
>> -------------------------------------------------------------------------
>>
>> You can't win with pylint...
>
> Probably that means it got confused by the alphabetization - "pyodbc"
> should come before "re" and "requests", but "sqlite3" should come
> after. Either fix the first problem by splitting them onto separate
> lines, or ignore this as a cascaded error.
>
> My general principle is that things on one line should *belong* on one
> line. So having "import re, requests" makes no sense, but I might have
> something like "import os, sys" when the two modules are both used in
> one single line of code and never again. Otherwise, splitting them out
> is the easiest.


I like to put them on a related line.  Didn't know where re belonged, 
and I don't like putting them on single line each.



>>>> +-------------------------+------------+
>>>> |superfluous-parens       |3           | I like to surround 'or'
>>>>                                          statments with parens
>>>
>>>
>>> I would need examples to comment
>>
>>
>>
>> if ("Please choose a state" in str(matches)):
>> if (var == "val" or var2 == "val2"):
>
> Cut the parens. Easy!


Maybe.  I actually like my 'or' parens.  Habit maybe, because of this 
situation:

if (var == "val" or var2 == "val2") and (var3 == val3 or var4 == val4):




>> It says "Used builtin function 'filter'. Using a list comprehension can be
>> clearer. (bad-builtin)"
>
> Kill that message and keep using filter.


Unfortunately, 'bad-builtin' caught 2 truly bad uses of built-ins (zip() 
and id()), so I'll leave that warning in.


2.7.11 built-ins:

abs()	divmod()	input()	open()	staticmethod()
all()	enumerate()	int()	ord()	str()
any()	eval()	isinstance()	pow()	sum()
basestring()	execfile()	issubclass()	print()	super()
bin()	file()	iter()	property()	tuple()
bool()	filter()	len()	range()	type()
bytearray()	float()	list()	raw_input()	unichr()
callable()	format()	locals()	reduce()	unicode()
chr()	frozenset()	long()	reload()	vars()
classmethod()	getattr()	map()	repr()	xrange()
cmp()	globals()	max()	reversed()	zip()
compile()	hasattr()	memoryview()	round()	__import__()
complex()	hash()	min()	set()	
delattr()	help()	next()	setattr()	
dict()	hex()	object()	slice()	
dir()	id()	oct()	sorted()


I probably would've used dict as an object name at some point, too.

[toc] | [prev] | [next] | [standalone]

#108338

On Sun, May 8, 2016 at 2:40 PM, DFS <nospam@dfs.com> wrote:
>>> It says "Used builtin function 'filter'. Using a list comprehension can
>>> be
>>> clearer. (bad-builtin)"
>>
>>
>> Kill that message and keep using filter.
>
>
>
> Unfortunately, 'bad-builtin' caught 2 truly bad uses of built-ins (zip() and
> id()), so I'll leave that warning in.
>

Hrm, that would be called "shadowing" built-ins, not bad use of them.
Shadowing isn't usually a problem - unless you actually need id(),
there's nothing wrong with using the name id for a database key. Very
different from this message though.

ChrisA

[toc] | [prev] | [next] | [standalone]

#108333

On Sat, May 7, 2016, at 08:28 PM, DFS wrote:
> >> +-------------------------+------------+
> >> |superfluous-parens       |3           | I like to surround 'or'
> >>                                          statments with parens
> >
> > I would need examples to comment
> 
> 
> if ("Please choose a state" in str(matches)):
> if (var == "val" or var2 == "val2"):

Gah, don't do that. You're adding meaningless noise. 

Especially in the first case.

-- 
Stephen Hansen
  m e @ i x o k a i . i o

[toc] | [prev] | [next] | [standalone]

#108339

On Sat, May 7, 2016 at 9:28 PM, DFS <nospam@dfs.com> wrote:
> But I think there are some pylint bugs here:
> -------------------------------------------------------------------------
>
> standard import "import pyodbc, sqlite3" comes before "import pyodbc,
> sqlite3" (wrong-import-order)
>
>   * complains that the line comes before itself?

I think that it actually wants you to import sqlite3 (a standard
library module) before pyodbc (a third-party module). The message is
confusing because they happen to be on the same line. PEP8 has some
advice on import ordering, which this probably follows.

>
> -------------------------------------------------------------------------
>
> standard import "import re, requests" comes before "import pyodbc, sqlite3"
> (wrong-import-order)
>
>   * So I switched them, and then it complained about that:
>
> standard import "import pyodbc, sqlite3" comes before "import re, requests"
> (wrong-import-order)

Same thing. It wants the re import to come before pyodbc, and it wants
sqlite3 to come before requests.

[toc] | [prev] | [next] | [standalone]

#108352

Chris Angelico wrote:

> On Sun, May 8, 2016 at 1:28 PM, DFS <nospam@dfs.com> wrote:
>> Invalid constant name "cityzip" (invalid-name)
>> Invalid constant name "state" (invalid-name)
>> Invalid constant name "miles" (invalid-name)
>> Invalid constant name "store" (invalid-name)
>> Invalid variable name "rs" (invalid-name)
> 
> ... huh?? The first four seem to have been incorrectly detected as
> constants. How are they used?

As globals. pylint doesn't like it when you put your normal code outside a 
function, and I agree with the general idea. The problem is that it's not 
smart enough to recognize the exceptions like

plus_one = make_adder(1)

where plus_one obeys the naming convention for a function, but the linter 
asks you to change the line to

PLUS_ONE = make_adder(1)

In

Row = collections.namedtuple("Row", "alpha beta")

though pylint does recognize that collections.namedtuple() produces a class,
so there might also be a way to teach it how to handle the custom factory.

The OP should of course put the whole shebang into a main() function. That 
also simplifies it to determine which values should be passed as arguments 
when he breaks his blob into smaller parts.

[toc] | [prev] | [next] | [standalone]

#108291

On 5/7/2016 12:23 PM, Stephen Hansen wrote:
> On Sat, May 7, 2016, at 11:52 AM, Christopher Reimer wrote:
>> You can do better.  You should strive for 10/10 whenever possible,
>> figure out why you fall short and ask for help on the parts that don't
>> make sense.
> I think this is giving far too much weight to pylint's opinion on what
> is "good" or "bad" programming habits.

I forgot to add the warning, "Use pylint with a dash of salt on a lemon 
slice and a shot of tequila." :)

Thank you,

Chris R.

[toc] | [prev] | [next] | [standalone]

#108292

On Sat, May 7, 2016 at 2:52 PM, Christopher Reimer <
christopher_reimer@icloud.com> wrote:

> On 5/7/2016 9:51 AM, DFS wrote:
>
>> Has anyone ever in history gotten 10/10 from pylint for a non-trivial
>> program?
>>
>
> I routinely get 10/10 for my code. While pylint isn't perfect and
> idiosyncratic at times, it's a useful tool to help break bad programming
> habits.
>

I’m impressed with 10/10.
My approach is to ensure flake8 (a combination of pyflakes and pep8
checking) does not report any warnings and then run pyLint as a final
check.
Code usually ends up in the 9.0 to 9.5 range, sometimes a bit higher.
Also find it useful to add some additional short names we use to the
 allowed names list.

Biggest issue I have with pyLint is that it complains when function
parameters are indented twice vs. once. pyFlakes likes the twice.
Example:
def function_name(
        parm_1,
        long_parm_name,
        ….
        end_of_long_list_of params)
    parm_1 = long_parm_name

—Ray




-- 
Raymond Cote, President
voice: +1.603.924.6079 email: rgacote@AppropriateSolutions.com skype:
ray.cote

[toc] | [prev] | [next] | [standalone]

#108294

On 5/7/2016 12:52 PM, Ray Cote wrote:

> I’m impressed with 10/10.
> My approach is to ensure flake8 (a combination of pyflakes and pep8
> checking) does not report any warnings and then run pyLint as a final
> check.

I just installed pyflakes and ran it against my 10/10 files. It's not 
complaining about anything. So I ran it against my unit tests that I'm 
still writing, haven't cleaned up and checked against pylint. I got 
dinged for using a star import on a file with a common variables, which 
was an easy fix.

Thank you,

Chris R.

[toc] | [prev] | [next] | [standalone]

#108302

On Sun, May 8, 2016 at 4:42 AM, Michael Selik <michael.selik@gmail.com> wrote:
>
>> +-------------------------+------------+
>> |line-too-long            |5           | meh
>>
>
> Yeah, I think 80 characters can be somewhat tight. Still, 5 long lines in
> 200ish lines of code? Sounds like you might be doing too much in those
> lines or have too many levels of indentation.
> "Sparse is better than dense"
> "Flat is better than nested"

Others have commented on this, but I'll weigh in with one point that
hasn't been mentioned yet. A lot of tools will complain when you
exceed 80 (or 79) characters per line; but it depends somewhat on *how
far* you exceeded it. Some people opt instead for a 100-character
limit, or even 120, but most programmers agree that a 200-character
line (or more!) is too long.

So if this is complaining about five lines out of your entire program
that just snuck over the 80-character limit (eg 86 characters long),
it's not a concern, and my recommendation would be to relax the
restriction. And if those few lines are ginormous hunks of data
(static list initialization, or something), you might consider dumping
them out to external files rather than wrapping them into big code
blocks. But if they're truly long lines of code, wrap or split them.

ChrisA

[toc] | [prev] | [next] | [standalone]

#108316

On 5/7/2016 3:52 PM, Ray Cote wrote:

> Biggest issue I have with pyLint is that it complains when function
> parameters are indented twice vs. once. pyFlakes likes the twice.
> Example:
> def function_name(
>         parm_1,
>         long_parm_name,
>         ….
>         end_of_long_list_of params)
>     parm_1 = long_parm_name

This is the recommendation in PEP 8.  I would otherwise insert a blank 
line before the body.

tjr

[toc] | [prev] | [next] | [standalone]

#108326

On Sun, 8 May 2016 02:51 am, DFS wrote:

> This more-anal-than-me program generated almost 2 warnings for every
> line of code in my program.  w t hey?
> 
> 
>                                            DFS comments
> +-------------------------+------------+ -------------------------------
> |message id               |occurrences |
> +=========================+============+
> |mixed-indentation        |186         | I always use tab

Obviously not. There are 186 occurrences where you use mixed tabs and
spaces.

Try running Tabnanny on you file:

python -m tabnanny <path to your file>


> +-------------------------+------------+
> |invalid-name             |82          | every single variable name?!

Maybe. What are they called?


> +-------------------------+------------+
> |bad-whitespace           |65          | mostly because I line up =
>                                           signs:
>                                           var1  = value
>                                           var10 = value

Yuck. How much time do you waste aligning assignments whenever you add or
delete or edit a variable?


> +-------------------------+------------+
> |trailing-whitespace      |59          | heh!
> +-------------------------+------------+
> |multiple-statements      |23          | do this to save lines.
>                                           Will continue doing it.

Why? Do you think that there's a world shortage of newline characters? Is
the Enter key on your keyboard broken?


> +-------------------------+------------+
> |no-member                |5           |
> 
> "Module 'pyodbc' has no 'connect' member"   Yes it does.
> "Module 'pyodbc' has no 'Error' member"     Yes it does.
> 
> Issue with pylint, or pyodbc?

*shrug* More likely with Pylint.


> +-------------------------+------------+
> |line-too-long            |5           | meh
> +-------------------------+------------+
> |wrong-import-order       |4           | does it matter?

Probably not. I'm curious what it thinks is the right import order.



> +-------------------------+------------+
> |missing-docstring        |4           | what's the difference between
>                                           a docstring and a # comment?

Comments exist only in the source code.

Docstrings are available for interactive use with help(), for runtime
introspection, and for doctests.

https://docs.python.org/2/library/doctest.html


> +-------------------------+------------+
> |multiple-imports         |2           | doesn't everyone?

You mean something like this?

import spam, ham, eggs, cheese

*shrug* It's a style thing.


> +-------------------------+------------+
> |consider-using-enumerate |2           | see below [1]

Absolutely use enumerate.


> +-------------------------+------------+
> |bad-builtin              |2           | warning because I used filter?

Well that's just stupid. Bad PyLint. This should absolutely not be turned on
by default.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#108335

On 5/7/2016 11:25 PM, Steven D'Aprano wrote:
> On Sun, 8 May 2016 02:51 am, DFS wrote:
>
>> This more-anal-than-me program generated almost 2 warnings for every
>> line of code in my program.  w t hey?
>>
>>
>>                                            DFS comments
>> +-------------------------+------------+ -------------------------------
>> |message id               |occurrences |
>> +=========================+============+
>> |mixed-indentation        |186         | I always use tab
>
> Obviously not. There are 186 occurrences where you use mixed tabs and
> spaces.


I mean I always use tab after :

The program won't run otherwise.  If I use spaces, 100% of the time it 
throws:

IndentationError: unindent does not match any outer indentation level




> Try running Tabnanny on you file:
>
> python -m tabnanny <path to your file>


Didn't seem to do anything.



>> +-------------------------+------------+
>> |invalid-name             |82          | every single variable name?!
>
> Maybe. What are they called?
>
>
>> +-------------------------+------------+
>> |bad-whitespace           |65          | mostly because I line up =
>>                                           signs:
>>                                           var1  = value
>>                                           var10 = value
>
> Yuck. How much time do you waste aligning assignments whenever you add or
> delete or edit a variable?

Lots.  It takes hours to add or delete 3 whitespaces.



>> +-------------------------+------------+
>> |trailing-whitespace      |59          | heh!
>> +-------------------------+------------+
>> |multiple-statements      |23          | do this to save lines.
>>                                           Will continue doing it.
>
> Why? Do you think that there's a world shortage of newline characters? Is
> the Enter key on your keyboard broken?

I do it because I like it.

if verbose: print var

python doesn't complain.





>> +-------------------------+------------+
>> |no-member                |5           |
>>
>> "Module 'pyodbc' has no 'connect' member"   Yes it does.
>> "Module 'pyodbc' has no 'Error' member"     Yes it does.
>>
>> Issue with pylint, or pyodbc?
>
> *shrug* More likely with Pylint.



>> +-------------------------+------------+
>> |line-too-long            |5           | meh
>> +-------------------------+------------+
>> |wrong-import-order       |4           | does it matter?
>
> Probably not. I'm curious what it thinks is the right import order.


"wrong-import-order (C0411):
  %s comes before %s Used when PEP8 import order is not respected 
(standard imports first, then third-party libraries, then local imports)"

https://docs.pylint.org/features.html



I think there are some pylint bugs here:
-------------------------------------------------------------------------

standard import "import pyodbc, sqlite3" comes before "import pyodbc, 
sqlite3" (wrong-import-order)

   * complains that the line comes before itself?

-------------------------------------------------------------------------

standard import "import re, requests" comes before "import pyodbc, 
sqlite3" (wrong-import-order)

   * So I switched them, and then it complained about that:

standard import "import pyodbc, sqlite3" comes before "import re, 
requests" (wrong-import-order)

-------------------------------------------------------------------------





>> +-------------------------+------------+
>> |missing-docstring        |4           | what's the difference between
>>                                           a docstring and a # comment?
>
> Comments exist only in the source code.
>
> Docstrings are available for interactive use with help(), for runtime
> introspection, and for doctests.
>
> https://docs.python.org/2/library/doctest.html

Thanks


>> +-------------------------+------------+
>> |multiple-imports         |2           | doesn't everyone?
>
> You mean something like this?
>
> import spam, ham, eggs, cheese
>
> *shrug* It's a style thing.

pylint gives you demerits for that.



>> +-------------------------+------------+
>> |consider-using-enumerate |2           | see below [1]
>
> Absolutely use enumerate.


Everyone else says so, too.  But other than cleaner-looking code, I'm 
not understanding how it's a real advantage over:

for j in range(len(list)):




>> +-------------------------+------------+
>> |bad-builtin              |2           | warning because I used filter?
>
> Well that's just stupid. Bad PyLint. This should absolutely not be turned on
> by default.


It says "Used builtin function 'filter'. Using a list comprehension can 
be clearer. (bad-builtin)"

[toc] | [prev] | [next] | [standalone]

#108336

On Sun, May 8, 2016 at 2:10 PM, DFS <nospam@dfs.com> wrote:
>>> +-------------------------+------------+
>>> |trailing-whitespace      |59          | heh!
>>> +-------------------------+------------+
>>> |multiple-statements      |23          | do this to save lines.
>>>                                           Will continue doing it.
>>
>>
>> Why? Do you think that there's a world shortage of newline characters? Is
>> the Enter key on your keyboard broken?
>
>
> I do it because I like it.
>
> if verbose: print var
>
> python doesn't complain.

That's a massively-debated point. In that specific example, I'd
support the one-liner; however, I'd also recommend this technique:

# for Python 2, you need to start with this line
from __future__ import print_function

if verbose:
    verbiage = print
else:
    def verbiage(*args): pass

Then, instead of "if verbose: print(var)", you would use
"verbiage(var)". Of course, you want something better than "verbiage"
as your name; the nature of your verbose output might give a clue as
to what name would work.

ChrisA

[toc] | [prev] | [next] | [standalone]

#108350

On Sun, 8 May 2016 14:21:49 +1000
Chris Angelico <rosuav@gmail.com> wrote:
> if verbose:
>     verbiage = print
> else:
>     def verbiage(*args): pass

I have never understood why the def couldn't start on the same line as
the else:
 
if verbose: verbiage = print
else: def verbiage(*args): pass
 
The colon effectively starts a block so why not allow it?
 
By the way, I think you meant "def verbiage(*args, **kws): pass"

> Then, instead of "if verbose: print(var)", you would use
> "verbiage(var)". Of course, you want something better than "verbiage"
> as your name; the nature of your verbose output might give a clue as
> to what name would work.

How about "print"?

if not verbose:
    def print(*args, **kws): pass
    
-- 
D'Arcy J.M. Cain
Vybe Networks Inc.
http://www.VybeNetworks.com/
IM:darcy@Vex.Net VoIP: sip:darcy@VybeNetworks.com

[toc] | [prev] | [next] | [standalone]

#108351

On Sun, May 8, 2016 at 10:50 PM, D'Arcy J.M. Cain
<darcy@vybenetworks.com> wrote:
> On Sun, 8 May 2016 14:21:49 +1000
> Chris Angelico <rosuav@gmail.com> wrote:
>> if verbose:
>>     verbiage = print
>> else:
>>     def verbiage(*args): pass
>
> I have never understood why the def couldn't start on the same line as
> the else:
>
> if verbose: verbiage = print
> else: def verbiage(*args): pass
>
> The colon effectively starts a block so why not allow it?

Having two colons makes it a bit messy, so I can fully accept that
this *shouldn't* be done. Whether or not it's reasonable that it
*can't* be done is a question for the parser; but even if the parser
permitted it, I would expect style guides to advise against it.

> By the way, I think you meant "def verbiage(*args, **kws): pass"

In the general case, yes. But in this specific case, I actually prefer
not to accept keyword args in a null function; maybe permit sep=" "
and end="\n", but if someone sets file or flush, it's probably a
mistake (you most likely don't want verbiage("message", file=logfile)
to silently not do it). YMMV; maybe you want that, so yeah, toss in
the kwargs absorber.

>> Then, instead of "if verbose: print(var)", you would use
>> "verbiage(var)". Of course, you want something better than "verbiage"
>> as your name; the nature of your verbose output might give a clue as
>> to what name would work.
>
> How about "print"?
>
> if not verbose:
>     def print(*args, **kws): pass

The danger of that is that it's too general. I like to recommend a
little thing called "IIDPIO debugging" - If In Doubt, Print It Out.
That means: If you have no idea what a piece of code is doing, slap in
a print() call somewhere. It'll tell you that (a) the code is actually
being executed, and (b) whatever info you put between the parens
(ideally, some key variable or parameter). Part A is often the
important bit :) The trouble with a verbose flag controlling all
print() calls is that IIDPIO debugging suddenly doesn't work; plus,
it's easy to copy and paste code to some other module and not notice
that you don't have a verbosity check at the top, and then wonder why
disabling verbose doesn't fully work. Both problems are solved by
having a dedicated spam function, which will simply error out if you
didn't set it up properly.

But again, if you know what you're doing, go for it! This is exactly
why print became a function in Py3 - so that you *can* override it.

ChrisA

[toc] | [prev] | [next] | [standalone]

#108382

On 05/08/2016 06:01 AM, Chris Angelico wrote:
[snip...]
> ...                                          I like to recommend a
> little thing called "IIDPIO debugging" - If In Doubt, Print It Out.
> That means: If you have no idea what a piece of code is doing, slap in
> a print() call somewhere. It'll tell you that (a) the code is actually
> being executed, and (b) whatever info you put between the parens
> (ideally, some key variable or parameter)...

My personal variation of IIPPID debugging is to use input() instead of print().  For example:

     input('x = {}, y = {} --> '.format(x, y))

Then the program stops at this point so you can examine the values.  <Enter> will continue the 
program or ^C will abort (if you see what the problem is now).  Of course this can't be used in 
all situations, but it's handy where it can.

Note that my personal preference is to stick that "-->" as a prompt at the end, but obviously 
this (or a similar marker) is optional.

[toc] | [prev] | [next] | [standalone]

#108393

On Mon, May 9, 2016 at 6:45 AM, Larry Hudson via Python-list
<python-list@python.org> wrote:
> On 05/08/2016 06:01 AM, Chris Angelico wrote:
> [snip...]
>>
>> ...                                          I like to recommend a
>> little thing called "IIDPIO debugging" - If In Doubt, Print It Out.
>> That means: If you have no idea what a piece of code is doing, slap in
>> a print() call somewhere. It'll tell you that (a) the code is actually
>> being executed, and (b) whatever info you put between the parens
>> (ideally, some key variable or parameter)...
>
>
> My personal variation of IIPPID debugging is to use input() instead of
> print().  For example:
>
>     input('x = {}, y = {} --> '.format(x, y))
>
> Then the program stops at this point so you can examine the values.  <Enter>
> will continue the program or ^C will abort (if you see what the problem is
> now).  Of course this can't be used in all situations, but it's handy where
> it can.
>
> Note that my personal preference is to stick that "-->" as a prompt at the
> end, but obviously this (or a similar marker) is optional.

Neat technique. Not something to use *every* time (and not always
sensible - eg you don't normally want to stall out a GUI thread), but
definitely worth keeping in the arsenal.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.python

csiph-web