check for use of input

[pjritee]

Now that we are using input for some problems it seems students thing they need to use input in other problems and that's probably causing a timeout that seems to be what is being reported by some students. It might be a good idea to add a check in the static analysis when input is not required. Also what happens if 1 input is required bu the student uses 2

[sapi]

Probably not a bad idea (at least for the first few problems which require functions with return statements).

Using too many inputs (or inputs where they're not required) shouldn't cause any timeouts; you'll get an EOFError instead. If there's a stray timeout around, it must be something else (probably the usual issues with while loops).

[jgat]

I haven't checked the implementation - if a question doesn't expect the student to read from stdin, does the test runner still replace sys.stdin with a mocked version that yields EOF, or does it leave sys.stdin alone? In the latter case, you probably would get a timeout waiting for input from the console.

[pjritee]

Good point - but we probably don't want to have the students see an EOF error either in this case???

[sapi]

It'll always mock it, so they'll always get the error. Student code isn't ever given access to the actual sys.stdin. (It doesn't do anything in particular to return EOF; it just replaces sys.stdin with StringIO(''))

EOFError isn't ideal, but tutors should be able to explain it pretty easily. I'm sure we could raise a custom error by mocking input if this ever turned into a serious issue.

[jgat]

If you're catching an EOFError, you easily have the option to display a more human-friendly error.

There's pros and cons of doing that. Pro: students will understand their error. Con: students won't be exposed to errors they will see in real life.

On Sun, 8 Mar 2015 14:39 Sean Purdon notifications@github.com wrote:

It'll always mock it, so they'll always get the error. Student code isn't ever given access to the actual sys.stdin.

EOFError isn't ideal, but tutors should be able to explain it pretty easily. I'm sure we could raise a custom error by mocking input if this ever turned into a serious issue.

— Reply to this email directly or view it on GitHub https://github.com/CSSE1001/MyPyTutor/issues/149#issuecomment-77776064.

[sapi]

It's not being caught anywhere; it just propagates through the unit test.

I'm not raising it, either; EOFError is just the standard input behaviour on an empty stdin (it's a bit hard to reproduce in console, as if you replace stdin the console will quit!)