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

kirby urner kirby.urner at gmail.com
Sat Sep 9 19:35:50 CEST 2006

On 9/9/06, John Zelle <john.zelle at wartburg.edu> wrote:

> This is like saying that Physics students have to start with General
> Relativity and Quantum Mechanics, because those are state of the art. No one
> is denying that it's good to teach GUI programming at some point. Is that the
> simplest way to introduce programming? My learning philosophy is to always
> search out the simplest thing that illustrates the principles I want my
> students to learn at the moment. Anything more complex is just adding noise
> and complicating the learning process.

I believe in "cave paintings" which means grossly simplified demos
that nevertheless give a sense of what's involved in the production

So a little show and tell around GUI programming in the intro session
is in order.  Not saying they'll be tested.  Just the teacher clicking
around, writing a quick "Hello World" box, filling in some blanks or
whathaveyou -- the kind of thing MSFT would showcase when advertising
Visual Studio to CEOs who'll probably never touch the stuff (CTO's

But mostly I'm advocating going to the other extreme:  drop GUI as a
topic and just code up a namespace, reach into the grab bag for
functions, like f(x) or cos(x).  We pretend kids don't have the
background, but if they did *any* work with a TI calculator or an
algebra course, they know about functions, at least tacitly.

My prerequisite for my Saturday Academy class is algebra only, and
typing above 30 a minute really helps (a lot of 'em are getting that
from chat rooms these days, buy a typing drill for home).

> While I accept the power of twiddling in the shell particularly as an
> educational tool (again, I come from a Lisp/Prolog tradition), this statement
> is just silly. How can you define "state of the art" for any "self" but your
> own. When I write a script to automate some routine task, I virtually always

I can define it for my gnu math teachers, the people I work with in
South Africa for example.

> use interactive text input. Why? Because the whole point is to make something
> routine and automatic. Why would I write a program that forces me to:
> Start Python
> Import a module
> Recall what I'm suppose to invoke and what information it needs.

Sounds like your "program" is one of these top-to-bottom
glued-together script thingys.  We don't teach that way.  Modules are
grab bags, perhaps containing rich data structures (lat/long
dictionary say).  Modules define namespaces, like boxes of chocolates
(Forest Gump understands).

This need to glue it all together with some main() -- why?  We compete
with that idea of "programming."  We're not a part of *that*
particular conspiracy.

Last week, we were working on phi and the fibonaccis.  Let's get back
to that now.  Pull out a file drawer (import) and behold: all our
favorite specimens (even the bugs are back).

> Instead I can write an incredibly simply script that I just click on, and when
> it needs information it prompts me for it. That's _my_ state of the art in
> programming for myself. And it's something I can teach students to do for
> themselves in very short order.

Yeah, we don't like that style.  OK for you, works for your students,
I think you're probably a dynamite teacher.  But...  we still don't
like that style.

Later on maybe, if/when they're committed to CS.  But this is just
basic numeracy here, and they already know about functions from

import math
math.cos( 90 * math.degrees)

-- that's what a first class might include.  If what stops 'em isn't
the Python syntax, but the trig, then we go over the trig.  Basic
numeracy.  All as a bundle.  Not your grandfathers math class (but
some hoped it'd be for their kids -- remember when the future was,
well, futuristic?).

> Whether I'm writing for myself or whether I want my students to be able to
> write the simplest possible useful programs for themselves and others, that
> involves textual input. I'll say it one more time: IO is fundamental to
> programming; the simplest universal form of IO deserves to be in the core
> language so that it is easily accessible and available everywhere the
> language runs. Pascal got that right and Python (pre 3000) has it right.

And I'm saying using the shell to trigger namespace events is (a)
closer to what a GUI is doing and (b) is fully usable I/O.  Use doc
strings to remind about inputs.  raw_input prompts are the new goto
(to be avoided if possible).

> > As teachers, we shouldn't be propagating the hidden assumptions that
> > go with raw_input, i.e. that there's this class if people out there
> > "too dumb" to know anything about namespaces or functions.
> >
> Translate this to any other discipline. Running with my physics example: "As
> teachers, we shouldn't be propogating the hidden assumptions that go with
> Newtonian mechanics, i.e. that there's this class of people out there 'too
> dumb' to know anything about quantum physics or general relativity."  Does

Right, but I see that as a self-serving analogy.  You're *defending*
the status quo.  Notice how CP4E goes for like "riding a bicycle" and
"driving a car".  Anyone can do it, no big deal.

I think CS has a reflex to fight "debasement" of programming into a
"what your grandmother knows" skill.  But that's what I *want* to have
happen, and expect grandmothers *will* have those skills in the not
too distant future.

Latin moms in Rio will tell The Monkey to block those Evil Toons
(point and click yes, but they custom-skinned the GUI, know how it
works from hours study. What, working class folk with the free time to
study what they used have to pay for, plus hold down a job?  What a

> that really make sense? The fact that there is more advanced stuff that they
> will surely learn in due course is in no way a justification for not teaching
> simpler, useful concepts first.

Nothing much simpler than import math, using the names.  Raw_input is
difficult by contrast.

Why don't calculators have raw_input?  They can't do I/O?  How about
dashboards?  Cockpit of an airplane.

We use control surfaces all day long.  That's what a namespace is, an
API.  You don't need to tie it all together with some main().  This
isn't a script.  It's a place to do work.  Namespaces are like
studios.  Event driven.  More GUI, less "programming" (in the 1960s

> > I'm saying this'll all be common knowledge soon.
> Define "soon." I see the same demographic as Brad Miller. My students are
> freshman in college who have never programmed. And frankly, I'm OK with that.

And frankly, I'm not.  High school too wasteful.  If it's really about
sports, which is OK with me, lets do more sports camps.  But for kids
who want academic rigor (another kind of sport), it's just not OK to
not even *offer* OO by the end of high school.

If USA voters want to keep that status quo, fine, but don't think the
rest of the world will think twice about thrashing us in the job
market if so.  Or were we planning to use the Pentagon to keep the
rest of the world stone aged, while we went on being mental couch
potatoes.  If so, think again.

Praise the Lord we have television.  If the schools have decided to
rust in irrelevance, letting it be OK that globalization passes us by,
then we can do what we did in Sesame Street, except at a much higher
level (still using puppets though -- some of them CGI).

Our Snake with __rib__ syntax makes fun cartoons on TV.  It slithers
around like Kaa, eating stuff (eat method).  Hah hah, the 3rd graders
laugh.  Gnu math is just better.

> > We'll know about 'strings' just as surely as we know about 'numbers'.
> >
> > Why?  Because "computer literacy" is not just for some tiny inner
> > circle.  It's just basic fluency.  Like my friend Gene Fowler puts it
> > (paraphrasing):  any poet worth his or her salt should know about XML
> > already. http://controlroom.blogspot.com/2006/08/more-cast.html
> None of the poets I know care a twiddle about XML. I guess we just move in
> different circles.
> --John

Guess we do.  But that's how it is with poets (few and far between).


More information about the Edu-sig mailing list