Hello there, I think this is not the first time this has happened to me. I am running PyLint on Travis, and as of recently, I fixed the PyLint version to be ==2.0.0 which is still up to date. However, now it installs Astroid 2.0.1 which causes this: nuitka/nodes/NodeBases.py:273 E0237 assigning-non-slot NodeBase.setCompatibleSourceReference Assigning to attribute 'effective_source_ref' not defined in class slots nuitka/nodes/NodeBases.py:272 I0021 useless-suppression Useless suppression of 'attribute-defined-outside-init' The name or kind of message that PyLint outputs changed here it seems. Plus I am getting what I consider a false alarm: nuitka/Errors.py:37 E1133 not-an-iterable NuitkaNodeError.__str__ Non-iterable value self.args is used in an iterating context This is self.args from Exception, as can be seen in the code here: class NuitkaErrorBase(Exception): pass class NuitkaNodeError(NuitkaErrorBase): # Try to output more information about nodes passed. def __str__(self): from nuitka.codegen.Indentation import indented parts = [""] for arg in self.args: if hasattr(arg, "asXmlText"): parts.append(indented("\n%s\n" % arg.asXmlText())) else: parts.append(arg) parts.append("") parts.append("The above information should be included in a bug report.") return '\n'.join(parts) And then another regression: nuitka/nodes/NodeMetaClasses.py:66 E1121 too-many-function-args NodeCheckMetaClass.__new__ Too many positional arguments for classmethod call for this: return ABCMeta.__new__(cls, name, bases, dictionary) But my question basically it, do I need to also fixate the astroid version, so that I can be sure that a PyLint 2.0.0 is behaving like another PyLint 2.0.0 ? This has been driving me nuts this morning, sort of. Yours, Kay
Hello there,
nuitka/nodes/NodeBases.py:273 E0237 assigning-non-slot NodeBase.setCompatibleSourceReference Assigning to attribute 'effective_source_ref' not defined in class slots nuitka/nodes/NodeBases.py:272 I0021 useless-suppression Useless suppression of 'attribute-defined-outside-init'
The code of mine does this as of recently: __slots__ = "parent", "source_ref" # Avoid the attribute unless it's really necessary. if Options.isFullCompat(): __slots__ += ("effective_source_ref",) That saves a bunch of memory. Basically I have an optional slot, that is only assigned when necessary, when Nuitka is run in a non-default mode used for testing. But PyLint now goes with the first slot declaration and complains. So that is a bug in a new feature or a regression. Yours, Kay
Hi Kay, The 2.0 vs 2.0.1 problem you're experiencing with astroid was a problem with the 2.0 release. Due to a mistake in the release process, the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz sdist though was containing the actual 2.0 code. Not sure how the dev release got to be marked as 2.0 but only for the wheel file, but we added some additional documentation in the release process to ensure this doesn't happen again (although ideally we'd move the release to be an automatic process rather than manual as it is now) For the other issues, I suggest opening separate issues on the bug tracker since otherwise they can get lost here. Sorry for the trouble. Cheers, Claudiu On 22 July 2018 at 10:16, Kay Hayen <kay.hayen@gmail.com> wrote:
Hello there,
nuitka/nodes/NodeBases.py:273 E0237 assigning-non-slot NodeBase.setCompatibleSourceReference Assigning to attribute 'effective_source_ref' not defined in class slots nuitka/nodes/NodeBases.py:272 I0021 useless-suppression Useless suppression of 'attribute-defined-outside-init'
The code of mine does this as of recently:
__slots__ = "parent", "source_ref"
# Avoid the attribute unless it's really necessary. if Options.isFullCompat(): __slots__ += ("effective_source_ref",)
That saves a bunch of memory. Basically I have an optional slot, that is only assigned when necessary, when Nuitka is run in a non-default mode used for testing.
But PyLint now goes with the first slot declaration and complains. So that is a bug in a new feature or a regression.
Yours, Kay _______________________________________________ code-quality mailing list code-quality@python.org https://mail.python.org/mailman/listinfo/code-quality
Hello Claudiu,
The 2.0 vs 2.0.1 problem you're experiencing with astroid was a problem with the 2.0 release. Due to a mistake in the release process, the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz sdist though was containing the actual 2.0 code. Not sure how the dev release got to be marked as 2.0 but only for the wheel file, but we added some additional documentation in the release process to ensure this doesn't happen again (although ideally we'd move the release to be an automatic process rather than manual as it is now)
For the other issues, I suggest opening separate issues on the bug tracker since otherwise they can get lost here.
First of all, shit happens, and not a huge problem of course. I have done similar. Automation is fine, but not necessary less error prone. My static web site deployment e.g. managed to revert to 2 years old site due to a wrongly set RTC clock, turning all of 2 years of posts into drafts. But it it is less work, and you got a machine to blame. ;-) I was mainly wondering if Astroid had an independent release process. And I was wondering if there shouldn't have been a 2.0.1 release then for PyLint too. What's bound to be happening is that lots of people have "pylint" latest installed, but not the real thing. And nothing can make them notice. A bump of version on PyPI would be nice, not sure if you want to go 2.0.1 there too, might be used in your roadmap thinking already, or of 2.0.0a is even allowed anymore these days. I was of course going to report the issues to the bug tracker and just did. Unfortunately it also indicates that it's not a minor thing, that is changed, like a forgotten version bump, clearly more is in there missing for people who installed it during the time the wheel was not updated. Yours, Kay
Hi Kay, Astroid pretty much has an independent release process, but when necessary we release them both together, for instance when the API of astroid changes or when there's an important bug fix that all pylint users should have. I just bumped pylint to 2.0.1 as well, which includes a fix for a crash that was occurring when inferring `next()`. It also bumps the dependency of astroid to 2.0.1 so this should clear the installations that still uses the dev release of astroid. Thanks for creating those issues! I took a look at a couple of them and they seem genuine bugs. Thanks again! Claudiu On 23 July 2018 at 08:45, Kay Hayen <kay.hayen@gmail.com> wrote:
Hello Claudiu,
The 2.0 vs 2.0.1 problem you're experiencing with astroid was a problem with the 2.0 release. Due to a mistake in the release process, the wheel for 2.0 was in fact the last dev release of astroid. The .tar.gz sdist though was containing the actual 2.0 code. Not sure how the dev release got to be marked as 2.0 but only for the wheel file, but we added some additional documentation in the release process to ensure this doesn't happen again (although ideally we'd move the release to be an automatic process rather than manual as it is now)
For the other issues, I suggest opening separate issues on the bug tracker since otherwise they can get lost here.
First of all, shit happens, and not a huge problem of course. I have done similar. Automation is fine, but not necessary less error prone. My static web site deployment e.g. managed to revert to 2 years old site due to a wrongly set RTC clock, turning all of 2 years of posts into drafts. But it it is less work, and you got a machine to blame. ;-)
I was mainly wondering if Astroid had an independent release process. And I was wondering if there shouldn't have been a 2.0.1 release then for PyLint too.
What's bound to be happening is that lots of people have "pylint" latest installed, but not the real thing. And nothing can make them notice.
A bump of version on PyPI would be nice, not sure if you want to go 2.0.1 there too, might be used in your roadmap thinking already, or of 2.0.0a is even allowed anymore these days.
I was of course going to report the issues to the bug tracker and just did. Unfortunately it also indicates that it's not a minor thing, that is changed, like a forgotten version bump, clearly more is in there missing for people who installed it during the time the wheel was not updated.
Yours, Kay
participants (2)
-
Claudiu Popa -
Kay Hayen