[list-ops] Potential mismatch between instructions and tests

[OndrejMarsalek]

The instructions for append say "given two lists, add all items in the second list to the end of the first list". To me, a strict reading of this is that the first list should be modified (and then returned). In Python (and possibly other languages) it is possible to pass the tests by either modifying the first list and returning it, or by creating an entirely new list and returning that.

I think that either the instructions or tests should be updated to remove the ambiguity. I am not submitting a PR, as it is not clear to me what the original intention was. In my opinion, the instructions should be relaxed so that it is clear that the first list does not need to be modified.

I previously reported this for Python and was recommended reporting it here. exercism/python#3141

[iHiD]

My initial take on this would be that it's an implementation-choice by each language. In some languages mutation is considered normal and correct, in other languages it wouldn't be idiomatic. If there are languages where both are acceptable, a decision should probably be made. In Ruby for example, it would be normal to append an ! if a method mutates and not if it doesn't (e.g. list.uniq! mutates whereas list.uniq returns a new list).

I'd therefore suggest that tracks add an append file that specifies what is expected for that language.

[kotp]

Also, the ambiguity that may exist is definitely fodder for Mentor notes. If you solve it one way, then is there room to discuss the tradeoffs for doing it the other way in the language. As @iHiD indicates, it may not be a clear-cut decision. Ambiguity may exist to give some breathing room for the different languages that adopt the exercise.

I would suggest that the current version is "relaxed" and removing that ambiguity is the opposite of "relaxed", as it would be more stringent in what is demanded.

[OndrejMarsalek]

It makes sense to leave this very general and let track add details if/when appropriate. In the spirit of keeping it relaxed, I think it would be good to replace "add all items in the second list to the end of the first list" with something like "return (create? produce?) a list that contains all items from both lists", or something similar, so that modification is not implied if the instruction is read in its strict sense.

[OndrejMarsalek]

The current formulation might be motivated by the expected order of the items, so it might require yet another formulation, but I think it would be good to avoid "add ... to the end of the first list".

[BethanyG]

I like the wording "return a list that contains all items from both lists". I think I would fiddle with it a bit and make it into:

return a list that contains all items from A followed by all items in B.

We might then add an addendum on the Python track that talks about the options of either modifying list A, modifying list B, or creating a new list with elements from both A and B.

Perhaps as a hint file that says something like "There are few ways to solve this in Python, each with a tradeoff. We encourage you to explore the various options and think about why and where you'd use each of them."??

And as @kotp mentions, we could also add mentoring notes (we currently don't have any for this exercise for Python) that point at the various solutions, and the pluses and minuses.

[OndrejMarsalek]

I think that is all great, I agree.

[BethanyG]

Closing this to track changes under #3156 in the Python repo.