pylint woes

DFS nospam at dfs.com
Sun May 8 00:40:55 EDT 2016


On 5/7/2016 11:51 PM, Chris Angelico wrote:
> On Sun, May 8, 2016 at 1:28 PM, DFS <nospam at 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.





More information about the Python-list mailing list