Code style refinement to solve pylint error

[lryta]

@HrWangChengdu fixed pylint on travis. Could @hotpxl have a look at his Pylint options to check if the current configuration fits our project? (Do we need to turn on all the pylint options?)

After the confirmation of pylint options, we may distribute the work to fix the pylint error.

[jermainewang]

I think some lint options are too strict. I'm modifying the lint check and turn off some unnecessary ones.

[jermainewang]

Here are the lint error categories:

• invalid-name
• missing-docstring
• empty-docstring
• unidiomatic-typecheck
• line-to-long
• trailing-whitespace
• trailing-newlines
• multiple-statements (on single line)
• bad-whitespace
• bad-continuation
• multiple-imports
• wrong-import-order
• wrong-import-position
• no-self-argument
• import-error
• undefined-variable
• no-member
• dangerous-default-value
• pointless-statement
• pointless-string-statement
• expression-not-assigned
• exec-used
• attribute-defined-outside-init
• protected-access
• arguments-differ
• abstract-method
• super-init-not-called
• unnecessary-semicolon
• bad-indentation
• deprecated-module
• fixme
• unused-import
• unused-variable
• unused-argument
• redefined-outer-name
• redefined-builtin
• undefined-loop-variable
• cell-var-from-loop
• bare-except
• broad-except
• logging-format-interpolation
• deprecated-method

I think most of them should be fixed. Here are some exceptions:

• fixme should be allowed.
• protected-member and invalid-name could be disabled locally.

What do you guys think? @hotpxl @lryta @HrWangChengdu

[lryta]

I agree with your proposal @jermainewang

[Taco-W]

I agree @jermainewang . I suggest we start working in this rule and give feedbacks if other exceptions are found to be necessary later.

[hotpxl]

I agree. Mandatory checks may be less strict but we could still recommend more strict checks for developers.

[jermainewang]

Solved.