Repository navigation
[W1114 arguments-out-of-order] : Possible Severity Mis-match and Issue with Sublist Exercise #82
Description
Activity
@Yrahcaz7 - Happy to discuss details and possible remediations here. 😄
Reacted by YrahcazWould it be possible to disable
W1114for the exercise, or perhaps giveW1114a custom message for Sublist that's more specific to the exercise?These are the two options that immediately come to mind, but I'm not sure if either is possible (or just really hard) to implement with how the Analyzer works.
Edit: I also think that the general case of
W1114should probably be a lower severity and perhaps have a different message. Since the solution should have passed the tests to receive Analyzer feedback, it's unlikely that the parameters are actually in the wrong order, which is whatW1114implies.Reacted by BethanyGWould it be possible to disable W1114 for the exercise, or perhaps give W1114 a custom message for Sublist that's more specific to the exercise?
Both are possible.
The first (and probably easier) requires a pylint config file or directive for
sublistto turn off the rule. I would probably favor an exercise config in the Analyzer over a directive in the stub, because I really don't want to widely advertise that students can put pylint directives into their code and have the Analyzer follow them. 😉The second requires we write a pylint checker with a different ID. So it's a tad more involved, but quite possible — especially given that we have an existing rule we can adapt.
These are the two options that immediately come to mind, but I'm not sure if either is possible (or just really hard) to implement with how the Analyzer works.
Is this a low-key request to pick at the Analyzer? 😉 I have to say that I inherited some of the code, and haven't exactly done a whole lot to clean it up. But we could try some things together if you'd like. We could start with how we'd adapt this rule or change the feedback to better address the issues. And fiddle with some per-exercise configs and feedback.
Edited to add: Option three is to write a set of checkers just for this exercise. That's the most difficult path (more checkers, more testing, more opportunities for bugs), but the most customizable. I'd have to do some digging, since the outright-custom (see two-fer code) stuff is terribly brittle, so I'd probably favor doing PyLint style rules/config, but would then need to think through how to wire all that up.
I've been resisting the urge to pick at it, as I probably already have enough on my plate 😆. In my opinion, using a Pylint config file to ignore the rule for the exercise seems like a decent, fairly easy solution (though I do think that
W1114overall should be lower severity).Reacted by BethanyG
From the Forum Post.