Intro to python course - printing multiple things at once graded incorrect

[machow]

Leafing through the intro python course. One thing I've noticed is that people sometimes try to print two things (e.g. print(1, 2)), but this is rejected by the SCT (which expects two print statements). The green line is a common user submission.

This could be addressed by modifying the instructions, etc.. I didn't look closely enough to get a good sense for just how common this is, but wanted to leave a note here in case it ends up being useful.

cc @filipsch @ramnathv

[ramnathv]

This is great @machow! Your diff-viewer tool is super-useful in figuring out why users end up with an incorrect response. Coming to the printing issue, In general, I am not a big fan of instructions that explicitly ask users to print stuff, and we test them. It opens up a lot of ambiguity without adding much to the exercise experience. In R, for example, I have seen users use head, str etc for the same instruction. Forcing them to use one way to inspect an object seems to be constraining. I would love to hear more thoughts on this.

[machow]

@ramnathv I agree, it seems like users having everything but a final print statement for their result is a common cause of rejecting code, but I couldn't give a good solution.

In general it seems to be a symptom of having to find something in a relatively large amount of code. print statements, or assigning a result to a variable are essentially methods for having a concrete place for the SCTs to look (for the print statement it both makes the code easier to search for, and opens the option of checking output).

[ramnathv]

@machow You raise some good points. However, I am not sure how printing an object out adds additional power to the SCTs. If the SCTs have the object available, cant they automatically test its contents against those of the solution (test_object) or alternatively, have a test function that automatically prints the output of an object and tests its contents. This way, we can avoid having to make users print objects out to pass tests.

[machow]

@ramnathv

if the SCTs have the object available, cant they automatically test its contents against those of the solution

Yeah, that's one of the two common strategies for helping SCTs find results--printing and assigning to a variable.

This way, we can avoid having to make users print objects out to pass tests.

Agreed! At it's core, I think the issue is that people building early python courses hit a dilemma: to grade their code, students had to learn about variable assignment or function calls (print). print is introduced immediately in intro python for this purpose. (Unlike R courses, print is necessary to produce output).

[filipsch]

Interesting discussion, but I fail to see immediate action points from this discussion that requires changes to pythonwhat.

This looks to me more like an education problem: explaining CDs the different ways in which students print out solutions, and making sure to accommodate for those in their SCTs. If patterns emerge ("we're using the same combo of 4 functions every time we want to check for behavior X"), pythonwhat can step in.

Nevertheless, interesting thoughts. Closing for now, but keeping a reference to it to put in a 'features' or 'ideas' repo for content engineering as soon as that is created.

[machow]

edit: wait, I'm an idiot and just re-read your above comment which answers my question :o (coffee bring me strength)

@filipsch it may not reflect an immediately actionable piece for pythonwhat, but it does reflect a grading and feedback issue within python exercises--student behavior is at odds with the SCTs. Useful fixes might be SCT changes, content changes, or both. Is there a place to raise issues that touch both grading and feedback tools, as well as content? I want to make sure we don't silo around one or the other (especially since pythonwhat has traditionally not been a purely technical library, but a starting place for documenting grading systems in general at DataCamp).

(alternatively the issue may not be frequent or impactful enough to warrant changes--I'm fine with that as an option)