pylint woes

DFS nospam at dfs.com
Sun May 8 00:10:32 EDT 2016


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)"





More information about the Python-list mailing list