Hi Kay,

On 16 July 2018 at 13:56, Kay Hayen kay.hayen@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

On 07/16/2018 04:56 AM, Kay Hayen wrote:

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.

Hey, I'm finally in a minority. I have a code base that has to remain in Python 2, too. The issue is included code (via PIP) which isn't Python-3 safe yet.

Hi,

Another alternative would be to pin pylint for now to 1.9 so that it works out of the box for both Python 2 and 3. Also forgot to mention that we have plans to add support of linting Python 2 files while the running interpreter is Python 3 but we didn't have enough time before release to implement that: https://github.com/PyCQA/pylint/issues/2070. Once we have that feature, you can just have pylint 2.X installed and run it for both Python 2 and 3 linting.

On 17 July 2018 at 09:32, Kay Hayen kay.hayen@gmail.com wrote:

Hello Stephen,

...

...

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.

Hey, I'm finally in a minority. I have a code base that has to remain in Python 2, too. The issue is included code (via PIP) which isn't Python-3 safe yet.

But to be really in the minority, you have to run your code in Python2 and Python3 both.

And running PyLint for only Python3 wouldn't cut it, because testing for Python2 regressions would burn through massive amounts of CPU.

I am almost thinking, that minority is just me. :)

Yours, Kay _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality