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

Dethe Elza delza at livingcode.org
Thu Sep 7 01:22:54 CEST 2006

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).

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.  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 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=""):
     return sys.stdin.readline()

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.  Anyone can do it.  And the system isn't perfect, but if  
you're missing something, you have permission and ability to add it.   
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.

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.  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.

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


Young children play in a way that is strikingly similar to the way  
scientists work --Busytown News

More information about the Edu-sig mailing list