pylint 2.0 / astroid 2.0 released!
Hi folks, The pylint team is happy to announce the release of pylint 2.0 and astroid 2.0! This release only works with Python 3.4+, while older pylint releases are still maintained for Python 2 compatibility, at least until next year. You can find more details about what's new in this release over here: http://pylint.pycqa.org/en/latest/whatsnew/2.0.html Thanks and enjoy linting! Claudiu & all the Pylint contributors
Congratulations! This is a huge milestone! On Sun, Jul 15, 2018 at 4:54 AM, Claudiu Popa <pcmanticore@gmail.com> wrote:
Hi folks,
The pylint team is happy to announce the release of pylint 2.0 and astroid 2.0!
This release only works with Python 3.4+, while older pylint releases are still maintained for Python 2 compatibility, at least until next year.
You can find more details about what's new in this release over here: http://pylint.pycqa.org/en/latest/whatsnew/2.0.html
Thanks and enjoy linting! Claudiu & all the Pylint contributors _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
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
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
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
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.
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
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
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
participants (4)
-
Claudiu Popa -
Ian Stapleton Cordasco -
Kay Hayen -
Stephen Satchell