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

[Joshua Zucker]

Thanks, Kirby, for cluing me in that I hadn't posted it to the list.

--Joshua

---------- Forwarded message ----------
From: Joshua Zucker <joshua.zucker at gmail.com>
Date: Sep 8, 2006 2:07 PM
Subject: Re: [Edu-sig] The fate of raw_input() in Python 3000
To: kirby urner <kirby.urner at gmail.com>


On 9/8/06, kirby urner <kirby.urner at gmail.com> wrote:
> I think the model today is "a person writing code for him or herself"
> i.e. "self as client" -- at least in an early context.  We're not
> guiding the unknowing through a menu tree.  We're computer literate,
> fluent.
>
> Why would we ask ourselves for raw_input, when it's much easier to
> just pass arguments to functions?

As someone who has taught a lot of functional programming (Scheme), I
have a lot of sympathy for this argument.  It wouldn't occur to me to
teach raw_input or its equivalent anywhere early in the course,
because designing functions is what it's all about!

But the Scheme course I taught also came with a lot of teachpacks
(read: modules to import) that did things like provide an interactive
session with your function (prompting, like raw_input but with more
error handling built in, or GUI).  Without those, I might have been
tempted to teach those input functions after all.

The way my thinking is headed is toward event-driven programming
(prompted both by some Java books, for which I apologize, and by some
good new introductory Scheme lessons).  So I'd rather see some dynamic
thing, controlled by mouse clicks or key presses, as a relatively
"low-level" input function, instead of just raw_input().  But by then
I'd expect them to be comfortable with import anyway.

My feeling in favor of keeping raw_input() is that it gives one more
good choice for beginners.  One of the things I enjoy most about
Python is that whether I'm thinking like a Fortran programmer, a C
programmer, or a Scheme programmer, I still find myself for the most
part able to translate my thinking into reasonably good-looking code.
Sometimes raw_input() makes me feel like I'm thinking like a BASIC
programmer, but that has its place too, no?

My feeling against keeping raw_input() is that we don't want them
thinking that way anyway, and if someone really likes it, they should
just make their own module and import it, which is a good beginner
lesson.

This latest from Kirby, reminding us that instead of interactive input
we could just define a function and give the input that way, makes me
lean even more toward the "against" camp.  It'd be better education
without it.

--Joshua Zucker