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