For the Sublist practice exercise, any approach that uses a helper function gets [W1114 arguments-out-of-order] reported by Pylint, and it is marked as [Essential]. This is the case even for the correct approach in Dig Deeper.
(This happens because the helper function needs to be called with both helper(list_one, list_two) and helper(list_two, list_one).)
Possible fix: Disabling W1114 for the Sublist exercise. (Though I’m not sure if this is possible, as I’m not familiar with how the analyzers work.)
That does work, but having one function have list_one and another have something like first_list feels like a pointless inconsistency.
Also, with the feedback message calling the issue “essential” and “severe”, it might make one think that they shouldn’t use that approach, even though it is fine.
The message is also inherently confusing, as the “instead of … try” suggests changing something like the first code block to something like the second one, even though that would actually change the code’s function.
Analyzer feedback message
[Essential]
Line 14 [W1114 arguments-out-of-order] was reported by Pylint:
Positional arguments appear to be out of order.
There is an issue in the code that could lead to a bug or error in the program. While this error might not be severe, it could lead to more severe issues in the future. It is recommended the problem be addressed before proceeding further.
FYI the message “There is an issue in the code that could lead to a bug or error in the program.” is generic and applied to all Pylint warnings. It’s not set per-issue. The code examples are pulled directly from the Pylint docs.
I’m not a Python maintainer so I’m not putting forth any opinions about what ought or ought not be done here. Just mentioning options and explaining what’s happening.
As Isaac has said, we’ve mapped categories of PyLint messages to generic Analyzer message categories (you can see them here in the code), and rarely special-case . Warnings are a tad controversial at ESSENTIAL, but I’m keeping them there for now. I am still thinking through a re-arrangement/refactor to the code to allow more flexibility and customization, but we aren’t quite there yet.
The bad/good code examples are new, and pulled directly from PyLint documentation. They probably need some massaging, but we wanted to try them out for a while before considering refactoring or changes.
If you’d like to include this problem in the Approaches audit you are doing, we can noodle on some things to address it. I can also log an issue against the Analyzer where we can discuss different strategies to address it.