I've been thinking about your students and what possibly might be going on -- aside from their not learning anything, which unfortunately is possible. I think that you are better off trying to teach programming in conjunction with trying to teach test driven design, and unit tests. A large problem I see with people learning to program is that they try to do too much at once. As soon as they think of a a corner case, they rush off to write code about it, while it is fresh in theie mind. Quite often they end up with things that never quite work. And when they show you things, you can see 2 or 3 obvious bugs in the same code. Often they interact. So the poor student is busy trying to fix part A of his code when it is part B, or both part A and part B together that is the problem. What this student needs, more than anything else, is an ability to think in smaller chunks. Test driven design can really teach you to decompose your problem into tinier pieces. And, when you have a brilliant idea: -- Hey, this program should work when I type 'Mr. Andy Judkis' -- you can just stick this idea into a test, which will fail, but will make sure that you don't forget it for later -- but not get in the way of writing the basic program in the first place. and unittests teach you to write things in small chunks. unittests are nice for the teacher, as well, because you can assign 'write code that passes all these unit tests' and then write them in an orderly fashion, which will tend to influence how the students write their code -- starting small and then growing the problem -- much better than just telling them things. Plus you can sit down and run the test suite and have a pretty good idea how things are going before you start helping any student. But this doesn't sit all that well with your 'interactice loop' exercise. I wonder if it is the interactive loop part that is the problem. After all, if you cannot get that part going, it will be very hard to write the other bits. The last time I had students, and these were rather young ones -- I taught them first how to write programs that absolutely did something -- like print a list of the first 10, then 15, then 200 factorials. This lead to -- functions, and why we want them. Then it was time for test driven design, and how to run tests with our framework. We did a bunch of lessons like that before we got around to learning how to input things, and even then it was much more common for students to just have a running python interpreter, import their code, and pass arguments to functions rather than have a proper main loop. How to write functions, how to use them, how to use functions in the standard library. How to find out what the heck there _is_ in the standard library. How to use each other's functions, and a favourite, how to report a bug in your friend's function, complete with a unit test that demonstrates the bug. Despite all this experience, they found the actual getting and parsing of text from a user, _really_ _really_ _hard_. Much harder than anything else I had taught them before. And it was only when I did a fast-forward to 'Exceptions', which I had started out believing should be taught after classes, but now think should be taught as soon as you start doing input, and 'never mind the funny syntax that uses bits of the language we haven't learned about yet' that some of them caught onto what was going on. As your exercise stands, students who would not select yourself or 'Mrs. McGrath' would have a program that never terminated. I had several students who were really, really, uncomfortable with the idea, to the point of not being able to write code about it. They were waiting to think of the way to do it which didn't have this property. 'Real programs wouldn't work like that' they quite rightly complained. It was only after I had taught them about try: and except KeyboardInterrupt: that they were able to get down to write things. Before their minds were wrapped around what for them was the most interesting part of the problem, whcih wasn't the exercise. I guess the only way to find out is to ask your students. Good luck. [I should revise this, but I must pack for Europython. If I don't reply to replies to this, its not that I don't care, but that I expect to be completely swamped with running the conference for the next few days. In the words of Blaise Pascal -- sorry that this is so long, I do not have time to make it shorter.] Laura Creighton