Redefining built-in ‘filter’.
Redefining built-in ‘map’.
Redefining built-in ‘list’.
8 ERRORS
Redefining built ins might trigger a linter warning but shouldn’t be an error. It shouldn’t prevent the code from running, and you should be able to turn off the linter messages.
1 Like
But it is SUPER annoying is you do not want any errors
- It’s not an error.
- You can make it go away.
How do you do that?
Step 1: identify what is showing that message 
What’s showing that message? It’s not Python. It’s not the Exercism website. Where are you even getting that from?
List ops exercise
That’s a warning (W message) from Pylint. You can disable it by adding # pylint: disable=W0622 towards the top of your file.
@BethanyG I’m not sure how hard it is to add per-exercise Pylint configs but this might be a good place to ignore W0622.
1 Like
Not a Python maintainer, but some thoughts.
I think Pylint is correct that redefining a built-in is generally not a good idea. However, redefining a built-in specifically here serves a point. The instructions indicate we should “implement a series of basic list operations, without using existing functions” (emphasis is mine). If you don’t redefine, a student could with minimal effort use the built-in and not implement the underlying logic. Redefining adds just the slightest bit of friction so it has some use here whether Pylint indicates it’s a potential issue or not.
If we disable the rule, that suggests W0622 might not be an useful warning and can be ignored. I wonder if the analyzer could have a custom setup for this exercise where we can override how W0622 is surfaced. Then the surfaced guidance could say something along the lines of “Here’s an useful warning from Pylint that you should heed but on this exercise it doesn’t apply because …”
It requires per-exercise config files. Not sure I want to go there right now, but can add it to my longer-term list for when the Analyzer gets revamped.
2 Likes
The short answer here is no.
Longer answer; Yes - we can have a custom setup per exercise. It would require a pylint config file for each exercise, and custom rules for when we override specific messages and core Pylint rules.
In other words, if we want a special message here, we would need to reimplement the PyLint rule, tag it as a different rule number, and then use the exercise-specific config to turn on that rule and serve that message.
So it can go on the long-term list, but it won’t be getting done before the test runner refactor, the WASI stuff, or the upgrade to Python 3.14, and more syllabus work. 
But I also think the exercise could use a re-work. If this were the “real world”, a Pythonista might re-name the shadowing functions with one trailing underscore (see PEP8 on this), or they could be renamed list_special or some other convention, or they could be included in a class namespace that made it clear they were reimplementing built-ins.
I don’t think bare reimplementation would be done lightly or causally, because it would beak everything in the global namespace. This is why the Collections module provides UserString, UserList and UserDict – so that folx can customize the container types without shadowing in a destructive manner. So that might be another rewrite route for the exercise. We’d have to think about it.
So I think a “quick and dirty” fix could be to redo the tests and stub here to have those trailing underscores (which is a fairly easy fix in the template and the stub. Of course it would invalidate the 6,976 completed exercises, unless I could make the test logic a little fuzzy with the function names. A longer fix would be to redo the exercise to require customization of list through collections.UserList.
2 Likes
Thoughts on just slapping a pylint disable comment on those function signature lines as an alternative?
Thoughts on just slapping a pylint disable comment on those function signature lines as an alternative?
How does that teach fluency in Python or Python idioms? It makes skipping things that are real warnings for good reason cannon, rather than showing how Python conventions (in PEP 8) deal with them.
I’d rather change the exercise or depreciate it. Given the drama around it over the last several years (Misleading foldr tests, Refocus List Ops, and Bug in Python List Ops), it feels like maybe it’s outstayed its welcome. But if we do decide to keep it, it needs to be rewritten in a fashion that doesn’t encourage shadowing or other bad practice.
Whether that is using the trailing underscore kluge, renaming the functions, making it class-based, or making it an extension of collections.UserList — I don’t think solidifying pylint skips is the long-term answer.
3 Likes
I think that’d be my personal favorite. I’d be happy to help out however you might need when the time comes for an overhaul.
Please do that!
@BNAndras – Happy to have you take a shot at a rewrite/reconfigure using collections.UserList (or another method). Keep in mind you’d likely have to redo the JinJa2 template (but I could help with that), and we’d want to do some instruction appends to make it clear to implementors what we have in mind.
Bonus points if you can get the tests written in a way that would accommodate both older and newer solutions - but don’t spend too much effort on that, it isn’t a requirement. 
Just a little context: I am in the midst of planning an upgrade to Python 3.14. I was toying with using a free-threading build, but then took a hard look at what WASI supports, and realized I couldn’t really do that. None of that should really affect changing this exercise - but if you have a choice of Python envs, choose 3.14.7 for dev.