[code-quality] pylint 2.0 / astroid 2.0 released!

[Claudiu Popa]

Hi Kay,


On 16 July 2018 at 13:56, Kay Hayen <kay.hayen at gmail.com> wrote:
> Hello PyLint team,
>
> my congratulations too. I have a few questions though.

Thank you!


>
> First of all, I am going to maintain my code base for Python2 and
> Python3 dual lingo. Using both the Python2 and the Python3 variant of
> PyLint, in different major versions poses a problem.
>
> One thing I encounter is "too-many-statements", which was fixed a
> bunch I assume. Now if I whitelist those, I will get
> "useless-suppression" by PyLint 1.9.2 and will have to put that one
> too,
> which prevents me from noticing if it ever becomes unnecessary. I wish
> there was a way for me, to not only do pylint:
> disable=too-many-statements, but say pylint2:
> disable=too-many-statements
> and then only that "pylint2" version would consider it. But I assume,
> you don't care about people who still care about Python2 code
> correctness and Python3 correctness at the same time? It
> must be a clear minority that I am in.

I'm sorry, I don't quite understand what is the problem. Do you get
`too-many-statements` when using pylint with Python 2, but are you
not getting these when using pylint with Python 3?
If so, it might be because `too-many-statements` got some fixes
in Pylint 2.0, while it didn't for Pylint 1.9. If it's trivial to backport,
we can do it, as the 1.9 branch is going to be maintained for at least
a couple of months (2019 or so).
Regarding your second point related to filtering depending if it's
Pylint 2.0 or Pylint 1.9, I don't think it's necessary to have that
level of complexity.


> The other is the new message that I am getting in cases:
>
> nuitka\nodes\ExpressionBases.py:116 E1128 assignment-from-none
> ExpressionBase.getStrValue Assigning to function call which only
> returns None
>
> For code like this:
>
>     def getStringValue(self):
>         """ Node as string value, if possible."""
>         # Virtual method, pylint: disable=no-self-use
>         return None
>
>     def getStrValue(self):
>         """ Value that "str" or "PyObject_Str" would give, if known.
>
>             Otherwise it is "None" to indicate unknown. Users must not
>             forget to take side effects into account, when replacing a
>             node with its string value.
>         """
>         string_value = self.getStringValue()
>
>         if string_value is not None:
>             return makeConstantReplacementNode(
>                 node     = self,
>                 constant = string_value
>             )
>
>         return None

This one is tricky, because pylint cannot infer that you are relying on an
implementation class so that `getStringValue` method has a provided value
(if I understood correctly). If you use the `abc` module though, that
is, to mark
`getStringValue` as an abstract method, there's a chance you might not get this
error any longer (and if not, that's likely a bug that we should fix).


>
> Obviously I have disabled the "useless-return" immediately, I am not
> comfortable with explicit "None" returns not allowed, so do I have to
> white list those,
> because that is what virtual methods are for. I am not getting what
> this is about, is my pattern here so uncommon?

I don't recall exactly but I think it wasn't supposed to catch this particular
use case of no-body functions. Please submit it as an issue!

>
> Otherwise, I have a bug to report related to "bad-continuation", but I
> will do this to the tracker later today.

Sounds good, thanks!

>
> Generally I liked the new warnings, which lead to improved code, esp.
> the new chaining suggestions are full spot on.

Thank you!


Cheers,
Claudiu