Skip to content

[W1114 arguments-out-of-order] : Possible Severity Mis-match and Issue with Sublist Exercise #82

Description

@BethanyG

From the Forum Post.

Activity

  1. self-assigned this
    on May 17, 2026
  2. BethanyG commented on May 17, 2026

    @BethanyG
    MemberAuthor

    @Yrahcaz7 - Happy to discuss details and possible remediations here. 😄

  3. Yrahcaz7 commented on May 17, 2026

    @Yrahcaz7

    Would 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?

    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 W1114 should 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 what W1114 implies.

  4. BethanyG commented on May 17, 2026

    @BethanyG
    MemberAuthor

    Would 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 sublist to 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.

  5. Yrahcaz7 commented on May 17, 2026

    @Yrahcaz7

    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 W1114 overall should be lower severity).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions