Hello PyLint team,

my congratulations too. I have a few questions though.

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 might have to solve these warnings. In some places, I like to tolerate breaking those rules, if there is nothing to gain from breaking things up, say e.g. populating an option parser is going to be a lot of statements, that is just that then.

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

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?

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

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

Yours, Kay

Hello there,

...

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?

I am now getting them with Python3, I should have gotten them with Python2 all the time.

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).

That would be great. However, eventually there will be differences.

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.

I guessed so. Maybe I will have to drop PyLint for checking Python2 eventually. It's a pity, because it can really save a *lot* of CPU cycles for me. When PyLint finds an error in Nuitka, before I running a full test battery of endless compilations of Python codes that are not affected, to finally see what is normally visible to PyLint.

That complexity then ends up in my hands, e.g. with my own way of pre-processing files for PyLint, so that it would behave as I see it. Copying the source tree before checking to a temporary folder while replacing "pylint2: disable..." with nothing or with "pylint: disable" depending on PyLint version. Making your parser accept another keyword would therefore be great. Is this something a plugin could do for PyLint?

...

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).

Making it abstract would be counter productive, as it's also the default implementation to be used by most of the things. It is for overload really.

But I get it, there is no way of knowing. Maybe disable it for methods?

Thanks for your response, Kay

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

Hello Claudiu,

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.

That's great, thanks for going there. Subscribed to the issue. That will solve all the problems for me. I hope somebody tackles it. But just to be clear. I totally get it if it were not to happen.

For Nuitka I have chosen to run with the language version that I compile, so run time computations need not be abstracted. One idea I had was to have a slave Python interpreter on the target OS, target Python version, that does part of the work, e.g. "1+2L", while also caching results. So far, this has proven too crazy, but would enable cross compilation maybe.

Not sure how much compile time computations PyLint does. I assume it is quite a lot.

Yours, Kay