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 _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
