two-fer: Remove default parameter from solution stub

[xarxziux]

The Two-Fer exercise is quite a simple one which really requires only two pieces of knowledge in any language:

• How do you append strings?
• How do you create default parameters?

In Python, the first is trivial, while the second is slightly trickier. As written, the example code already provides the answer to the second question which is a massive spoiler, making the exercise far too easy in my opinion. With this PR, I propose that this be dropped from the exercise, leaving the student to work out how default parameters work for themselves.

[cmccandless]

@xarxziux I've asked some of the track mentor's to weigh in on this since this exercise is only the second in the core progression.

[edhaz]

Leaving it in:

• Ensures students move on quicker.
• Gets them to think about what a default value is if they've never come across it before. If they've not come across it before I doubt they'll pull it out of the blue, mentors will need to tell students, which leads on to:
• Can require less mentoring.

Taking it out:

• Makes the exercise trickier/longer, but also gets the student to think more.
• Will result in more 'conditional' answers. if else etc.

I'd be tempted to leave it in but could be persuaded otherwise.

[cmccandless]

Will result in more 'conditional' answers. if else etc.

Conditional answers won't cover the following usage:

two_fer()
two_fer("Alice")

Students familiar with other languages like C++ might attempt to use an overload instead, but that won't work in Python. Default argument is required by the tests because of this usage, so one way or another, the student will have to learn default arguments in this exercise, whether it's handed to them directly or not.

[edhaz]

Didn’t even think of that! Doh!

[iHiD]

I'm 👍 on removing it from the stub. In Ruby, pretty much everyone works it out (I don't think I've ever seen someone not work it out) and it leads to lots of interesting conversations as they often set the default value to be nil then have a conditional, which gets them to think about it. By having it in the stub, I think we're handing them too much of the answer.

[xarxziux]

By having it in the stub, I think we're handing them too much of the answer.

These are my thoughts exactly. I just came across it as a student and that was my impression.

[cmccandless]

I think the consensus is on removing the default argument, but there's still a problem with doing so: this would be the only exercise in the track that the Python interpreter cannot compile out-of-the-box.

Option	Pros	Cons
Leave Parameter without default value	Consistency with other exercises	Incongruous with first test case
Remove parameter entirely	Might provide a better hint on default parameters	Incongruous with all except first test case
Leave as-is	Python interpreter won't choke on solution template	Decreased learning opportunity

[yawpitch]

Personally I think this exercise opens up the opportunity for the student to learn several things:

1. default arguments
2. string concatenation, though this should naturally lead to...
3. string formatting, including printf-style, str.format, and f-strings.

Of the bunch I'd tend to argue the default argument is the easiest learned and the least valuable to their future progress.

Personally I'd go for:

def two_fer(name):
    pass

The first test will fail, as it should. They'll notice that no argument is being presented in by the test suite; they may decide to remove the parameter and return the required string and they'll pass test 1 but fail test 2 ... now they'll know and argument may or may not be presented, and this will lead them to default values.

[cmccandless]

Merged; thanks for working on this!