[Edu-sig] The fate of raw_input() in Python 3000

[John Zelle]

On Wednesday 06 September 2006 6:22 pm, Dethe Elza wrote:
> On 6-Sep-06, at 2:51 PM, John Zelle wrote:
> > I believe that a good language is one that provides a natural way
> > to express
> > algorithms as we think about them. Python is one of the very best I
> > have
> > found for that. I believe (for reasons already stated) it is less good
> > without raw_input and input.  That is and was the "tone" of the
> > discussion,
> > so I'm finding it hard to figure out what you take exception to.
>
> I understand the arguments for input() and raw_input(), and agree
> with them (despite my playing Devil's Advocate earlier in this
> thread).  I would like to see them renamed to be more descriptive of
> what they actually do (input() and eval_input() ?), but on the whole
> I agree that they are useful, especially if sys.stdin.readline is not
> equivalent anyway (but see below about that).

I would want to keep the original names if only for historical reasons.

> But I do understand where Arthur is coming from on this one.  A
> substantial part of the conversation has consisted of phrases like,
> "if Python does this, I'll look elsewhere," and "I wouldn't have
> chosen Python if not for input()."  Things like that do read like a
> threat, and they are overblown to say the least.  

I take exception to the word "threat" here. These are statements of intention. 
There are more Python-like languages all the time. If one of those ends up 
with a better constellation of features than Python for building a 
pedagogically sound curriculum, then folks will begin to switch. I think you 
will find that serious CS educators are always surveying the programming 
language landscape. These were honest opinions about input and raw_input 
helping attract us to Python. As I said, losing these takes away some of its 
charm. It's only a threat if you think we really have some influence over 
Guido :-). I've been trying to lay out rational arguments on a number of 
fronts.

> Python has a lot 
> going for it besides input(), to say the least.  If anyone really
> intended to stop using Python over that one, trivial, feature
> (useful, yes, but still trivial), then I don't see why they would
> stay with Python because of it.

It's a constellation of features. No language is perfect for everyone or every 
application. However, people with experience teaching have learned that 
language does matter when it comes to introductory programming. We are 
arguing for keeping these particular features in the constellation. Does one 
feature make or break? Of course not, unless it's the only real difference 
between two languages.

> It sure stirred up a lot of commentary though.
>
> >> But it is trivial to add this back in:
> >>>>> raw_input = sys.stdin.readline
> >
> > This is simply not equivalent. readline does not take a prompt as
> > an argument.
> > You'll have to write the function.
>
> Well, no, you don't really.  You could teach students to use print()
> or sys.stdout.write() for output (including the prompt) and
> sys.stdin.readline() for input.  Or you could write it:
> def raw_input(prompt=""):
>      sys.stdout.write(prompt)
>      return sys.stdin.readline()
>

Look at my previous comments, I said you'd have to write a function for it, 
which is what you did. 

> Heck, writing that (without having to understand it all) could be a
> great introduction to programming, by creating their own utility that
> they can use all the time they learn that there's nothing magic about
> programming.  

No, you've done just the opposite. You've taught them there's a magic 
incantation they don't yet understand. Students (at least at the level I see) 
are frustrated and feel patronized by things they are supposed to do without 
understanding. Then they think their job is to memorize. I don't want them to 
memorize, I want them to understand.

> Anyone can do it.  And the system isn't perfect, but if 
> you're missing something, you have permission and ability to add it.

That's an argument for teaching functions (and later classes), which of course 
we do. You might be surprised to learn that functions are one of the most 
difficult concepts for my students to grasp. It always surprises me the 
difficulty they have with this idea, even though it seems trivial to us. 
Again, a good feature of Python is that they don't have to tackle functions 
on day 1.

> My son learned to draw using perspective when he was three, not
> because he understood it, but because he watched what his older
> sister did and imitated her.  I don't understand the idea that we
> can't introduce things to students until they've understood all the
> underlying concepts--that's not how we learn anything else in life.

I don't think this is analogous, as drawing in perspective is not an 
analytical skill. Tiger Woods learned to golf at 3 without understanding 
anything about the golf swing or the physics of the game. Some skills can be 
learned (are best learned) by imitation. But imitating a computer programmer 
(at that level anyway) is just typing. Being able to type a program is not 
the same as programming.

Meeting the students where they're at, building on what they can already do, 
brick by brick, and allowing them to have success is the best way to 
motivate, in my experience. 

> To be honest, in thinking about teaching my nine-year-old and her
> classmates Python it never occured to me to teach them to use input()
> or raw_input().  I was going to go straight to PyGame, like LiveWires
> without the religion.

I have no experience teaching 9 year olds (my daughter's only 8, and I have no 
intention of teaching her programming at the moment, as she has more 
important things to learn like how to read fluently and add and subtract with 
ease, not to mention multiply). I do have lots of experience teaching college 
students. There is very little of _practical use_ I can teach them day 1 with 
something like PyGame. I _can_ teach them _and have them understand_ a 
program that will help them with their accounting homework. Or one that will 
answer a question about the risks of gambling. That's a program that they 
can't buy a better version of off-the-shelf. It's something specific to a 
problem at hand. It's something most of them couldn't do before I opened 
their eyes to a new tool. Or they can write a program to investigate a little 
chaotic function... Those things are conceptually and practically simpler at 
the command line. Basic bread and butter programming is input-process-output. 
Sure it's not flashy, but it's useful and they can understand it. Those two 
things can be strong motivators.

> Do you really teach students using the command- 
> line for programs?  I live at the command-line myself, but I don't
> expect that of others.  I would teach them how to build a GUI or at
> least use dialogs for user input--something that they can recognize
> and relate to.  I would certainly introduce the command-line at some
> point, but not so early that they'd be scared by a little dot notation.

Basic text-io is the simplest, least mysterious way to start programming. Any 
kind of GUI environment introduces tremendous intellectual overhead. You will 
have a hard time convincing me it's better to start with more complicated 
things and move on to the simpler. It just doesn't make sense. Even your 
three year old probably didn't start drawing in perspective by looking at a 
painting of the last supper.

>
> Of course, I'm a parent and an amateur teacher.  Your mileage may vary.

It does. But I would also be the first to admit that there is no 
one-size-fits-all solution to education. I'm sure many students would groove 
on a PyGame curriculum. I don't think it would best serve the majority of the 
students that I see in my classes, and there's not enough of me to tailor the 
curriculum to be a best fit for every single student.

It has been an interesting discussion. Now I need to get back to work figuring 
out how to educate my students tomorrow :-)

--John

-- 
John M. Zelle, Ph.D.             Wartburg College
Professor of Computer Science    Waverly, IA     
john.zelle at wartburg.edu          (319) 352-8360