[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=""):
sys.stdout.write(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.
--Dethe
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