[Python] Implement new Concept Exercise: list methods

[DavidGerva]

This issue describes how to implement the list methods concept exercise for the Python track, which should familiarize the student with the core list methods.

Getting started

Please please please read the docs before starting. Posting PRs without reading these docs will be a lot more frustrating for you during the review cycle, and exhaust Exercism's maintainers' time. So, before diving into the implementation, please read up on the following documents:

• The features of v3.
• Rationale for v3.
• What are concept exercise and how they are structured?

Please also watch the following video:

• The Anatomy of a Concept Exercise.

Goal

This concept exercise should familiarize the student with some of the core list methods that manipulate/mutate lists, and when/how to use them.

Learning objectives

• become familiar with the list class & its core methods
• understand when when it is appropriate to use the methods of a list to operate on it
• understand that these list methods mutate the list -- they do not return or make a new list.
• use several of the list methods -- one at least from each grouping below to mutate a list:
  • add a single element/multiple (iterable) elements to the end of a list with the append()/extend() methods
  • insert an element before a given index position in a list with the insert() method
  • remove element at the given index & return it for use/delete it with the pop()/remove() methods
  • re-arrange list elements in place with the sort()/reverse() methods
  • return a shallow copy of a list with the copy() method
  • return count of the elements in a list with the count() method
  • return the index of the element in a list with the index() method
• understand how the elements of two lists are compared

Out of scope

• performance considerations
• common sequence operations such as bracket notation, slice notation, min(), max(), and len()
• [related collections types](), such as deque & UserList
• list comprehensions
• map() and reduce() for operations on a list
• built-ins that can take a list as an argument
• understanding how the elements of two lists are compared
• shallow copy of a list with the copy() method vs deep_copy()

Concepts

• container types
• indexing
• iterables
• lists
• methods of list
• mutable, mutability
• sequences, sequence types

Prerequisites

• basics
• booleans
• iteration, iterables
• loops
• methods
• sequences

Resources to refer to

• Python list methods (Python language reference)
• Python list methods on python-ds
• Pythons Sequence Types
• Pythons built-ins

Hints

• Referring to one or more of the resources linked above, or analogous resources from a trusted source.

After

Explain more about:

• The differences between methods of list & Pythons built-in methods called with a list as argument (e.g. reversed(), sorted(), len() ...).
  • mutability and its benefits/pitfalls
  • The common sequence operations that apply to all sequence types (binary data, text strings, lists, tuples, range)
  • Two-dimensional and n-dimensional lists
  • Slice assignment (aka "mutation hell")

Representer

No changes required.

Analyzer

No changes required.

Implementing

Tests should be written using unittest.TestCase and the test file named comparisons_test.py.

Help

If you have any questions while implementing the exercise, please post the questions as comments in this issue.

Edits

-

[BethanyG]

🔥 🔥 🔥 -- @DavidGerva you are on a roll! Many thanks for this.

[BethanyG]

@mohanrajanr will be taking this on. YAY.

[mohanrajanr]

@DavidGerva @BethanyG : To Test this exercise, I came up with the following plan.

class ListWrapper(list):
    def __init__(self, iterable=(), **attr):
        super().__init__(iterable=iterable, **attr)
        self.execution_history = []
    def append(self, value):
        self.execution_history.append('append')
        super().append(value)
    def extend(self, value):
        self.execution_history.append('extend')
       super().extend(value)

a = ListWrapper()
a.append(1)
a
#=> [1]
a.execution_history
#=> ['append']

This looks like a more plausible way to understand whether the user used the function in the code. All the Test cases will be manipulating the list which we pass ( the list wrappered object is the one we will pass in the test ) and we can test all the list methods :) .

At first i thought whether we can monkey patch built in object or use decorator of some sorts, but listwrapper seemed more easier to do.

Thoughts?.

And Also, I know Jeremy has an Issue raised about differentiating on exercises and concepts. So Should I go on with the PR or should I wait?

[SleeplessByte]

This looks like a more plausible way to understand whether the user used the function in the code. All the Test cases will be manipulating the list which we pass ( the list wrappered object is the one we will pass in the test ) and we can test all the list methods :) .

As a rule on exercism, test don't test implementation. This has three reasons, if not more:

1. Testing implementation means that it will eventually break with best practices (idiomatic-ness), because there might be a new way in the future that is more idiomatic, but the tests won't allow for it.
2. Most forms of testing implementation gives away the answer, which is what we don't want.
3. You probably won't and shouldn't test implementation when writing this code in the wild, you'd test outcome.

However, we have a way to guide a student to use specific implementations! We allow analyzers to test implementation. This has a sidenote: we often suggest you only give feedback on proven positives, and not potential positives. What does this mean? Instead of analyzing "uses append", you would instead analyzer "uses for each" and suggest append. This way, when new ways are added in the future, the analyzer doesn't break!

[SleeplessByte]

And Also, I know Jeremy has an Issue raised about differentiating on exercises and concepts. So Should I go on with the PR or should I wait?

Just continue. You're doing great, and it's easy for us to "fix" / do another PR to update once that idea lands. No need to wait.

[mohanrajanr]

@SleeplessByte : Thanks for your comments.

You probably won't and shouldn't test implementation when writing this code in the wild, you'd test outcome.

Got it!. I think this line resonates better about the thought i should give on writing test cases.

it's easy for us to "fix" / do another PR to update once that idea lands.

Great. I will proceed working with this.

[mohanrajanr]

Created a PR for this Issue here : https://github.com/exercism/v3/pull/2303

[cmccandless]

I missed this issue when it was created. Was there a discussion at some point on naming this concept "list methods" instead of just "list"?

[BethanyG]

Yeah. That naming struggle (and grouping of concept and terms) is ongoing. We already have lists, but purposely limited the coverage of specific methods there.

I am debating if we do an iterables or sequences concept for things like bracket notation, indexing, slicing -- all the common sequence operations that apply across sequence types (help thinking through that warmly welcomed).

If we were to do that, then there is this space "in between" the basic data structures (what they are, if they are mutable, immutable, how to make one, how to update one) and the more general types and how those get used/interpreted (sequence, mapping, stream, etc.) where there are useful or important methods specific to only that class (str.join(), list.sort(), etc.). We also have a strings and string-methods (and in fact have string formatting). And I am assuming we'd probably have a dict-methods too. But I am not very happy with it - I just don't know yet what a better grouping is.

I'll admit that methods is an overloaded word - but operations (or operating on lists) doesn't really feel correct either. The docs use methods. Not that that recommends the term as a concept:

The list data type has some more methods. Here are all of the methods of list objects

Thoughts? These are things that are important for a student as basic building blocks, and I don't think the list exercise is detailed enough (nor should it be as a concept exercise) to then point the student to the List class and say "have at it!".

[cmccandless]

I'll admit that methods is an overloaded word - but operations (or operating on lists) doesn't really feel correct either. The docs use methods. Not that that recommends the term as a concept:

Not to mention that we also have a list-ops practice exercise...

I do like the idea of an iterables concept. Frequently in Python it doesn't matter what the exact type of a variable is; its behavior (or "group") is usually more important. It feels right to integrate that ideology to our concept exercises too.

[BethanyG]

Since PR #2303 has been merged 🎉 , I am closing this issue.