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

[kirby urner]

On 9/8/06, Joshua Zucker <joshua.zucker at gmail.com> wrote:
 > 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!

I don't think it's an accident that the Scheme community seems more
prepared to teach in a functional style, and treat .py namespaces as
fish tanks full of mouthy functions and class type initializers --
both callables.

Top-to-bottom executable scripting, with maybe forks in the road, as in:

dumb_user_says = raw_input("yes or no?: ")

and likely no going back if you answer it wrong:

confirm = raw_input("are you sure??")

Not that we don't like being asked a 2nd time, but there are other
ways to build in security.  You might have to actually go into the
source and uncomment something (standard in POSIX environments: cut
and paste a commented example, tweak and uncomment).  You might have
to tweak a permission.  Very likely, a program with consequences will
log its activities.  A big part of a sysop's job:  know where programs
leave audit trails ( /var/syslog or whatever).

Companies sometimes have manuals of style.  Code that's potentially
dangerous should be flagged as such.  Various conventions.  Often
there's a "no anonymous users" policy i.e. you can't run this code if
you're not willing to have your real name in the log as the user.  But
of course hackers are always looking for ways to bypass such
restrictions (sometimes to hack into their own systems, when they've
been a little too clever, and now can't remember the stupid passphrase
or whatever it was).  Very often, companies resort to physical
dongles, swipe cards, other hardware, to prevent unauthorized access.

Anyway, the most primitive module or namespace is the current session,
a kind of temporary scratch pad, where we cut and paste the "keepers"
to a "final draft" version.  Smalltalk has less of this sense of
"saving out to permanent storage" and keeps the current scratch pad as
the image (unless you don't save it).  I wonder about that workflow,
but realize you can internalize any file structure you like in an
image:  Smalltalk tends to seek the outer frame, and provide
everything internally (the tablet itself was the "smalltalk machine"
with "lid closed hibernation" -- since the 1960s at least).

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

People have different motives for getting into programming, which need
to be taken into account.  Some want to impress their mom's with "look
mom, no hands" GUI programs, others want to sit in a back office fine
tuning statistical analysis programs that will never see the light of
day, but which make the company tons of money and adds quality of life
to its customers as well.

I'm not saying any of these ways is "wrong".  But I think we should
acknowledge each language brings forward a sense of an interface.
Python's is most naturally a shell.  That's how it was designed.  And
that goes will with today's "unit testing" and "extreme programming"
best practices.  Work interactively at a work bench, debugging,
reloading, while saving out "keeper quality" work to intelligently
designed modules, properly populated with docstrings etc.

Kirby