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

[kirby urner]

On 9/10/06, Hugh Stewart <hughstewart at optushome.com.au> wrote:

> To cut to the chase: raw_input() provides an extremely useful
> I/O function for simple exercise type problems which are so essential
> in building a beginners repertoire of programming techniques and
> for 'John Zeller' type problems ( simple quick  dirty and effective
> solutions that get those housekeeping jobs done).

This is where you lose me Hugh, and not because I disagree about 'John
Zelle' type problems being useful.

What I wouldn't necessarily do is make my palindrome finder a
standalone script.

A Python module usually contains more than just a single function, and
everything you code and leave on the disk as a .py file is importable
as such (as a module), even if you run it directly.

The function to reverse a number might be reusable in another context.
 Functions are top level in Python.  You can feed them to each other.

In math class we teach about functions, usually with single-letter
names -- usually considered poor practice in CS -- and we teach kids
to feed arguments to these functions through mouth-looking pairs of
parentheses.

This is the kind of awareness I want a newbie to bring to a Python
module (a .py file) -- me and those who share my particular outlook in
this regard (I'm not speaking for the entire world here obviously).

A .py file should be more like a fish tank, full of fun little
performers that you gradually add to over time.  No main() need tie it
all together.  It's a vocabulary.  Life is full of 'em.

We know kids have the mental capacity, e.g. from sports, to track lots of names.

Someone objects:  but how are you supposed to remember what all these
functions do and what arguments they take?

Well that's a good question, but how is saving a program named
palindrome.py in some subdirectory any more self-explanatory, even if
it raw_inputs?  Where should we look for it?

There should be more documentation -- the perrenial need (Apple fought
against the "thick manual" aesthetic, recruited sensitive artist types
to our previously drab dweeby field).

The functional style is to feed functions through their mouths, not to
"pipe in" through intravenous -- a hole right in the body of a
function.

What I don't like about making palindrome.py a "script" (a standalone
.py file) is it fails to develop the sense of "being in a namespace",
which is what you get when you fire up the Python shell and import
one.

Suddenly dir() shows there's more here than just the builltins, lots
of little functions to feed, a whole fish tank of fun fishies, all
with proper names, presumably with docstrings to explain 'em.

My style of teaching beginners is:  teach 'em to "feed the fish" i.e.
to use functional notation (probably already familiar from math
class).  Use Python's dir() and help() facilities to remind oneself,
or explore for the first time, what's in a .py file.

Python modules are far better at self-documenting that brute file
systems at the OS level.  It's easier to document palindrome( ) in
funprograms.py, than it is to save palindrome.py and stuff text in
some readme.txt.

And we start coding "creatures" right away too.  A barking Dog, right
away -- maybe something the teacher writes, projected on the big
screen.  But at least we see it, understand the dot in mydog.bark(3)
is invoking an internal bark method.

Because modules are just naturally habitates for such class
definitions.  This is a really big part of the language, not some
bolted-on after thought.

OO is where it's at.  Not some "OO is 2nd year CS2 stuff" (like you're
joking right? -- you're *not* the world, right? (praise Allah we have
these alternative approaches)).

What's *in* a .py file may be a whole lot of Zelle-like short
programs, a box of chocolates, none of them more than 20 or so lines.
Maybe they call each other sometimes.  palindrome() invokes
reverseme() etc.  An ecology.  Stuff depending on other stuff.

Another way of saying it:  treat Python's shell, plus a code editor,
as your working environment.  You tweak the source, save, and
reload().  This is the work cycle when debugging for example.  If you
never drop out to the OS the entire hour, so what?

It's *not*:  run python myscript.py from the terminal window, prompt
myself for input, see the thing crash, then go open a text editor to
mess with the code.  That's *too hard* (unnecessarily hard).

All that work in the OS.  Why are we messing with the OS so directly?
That's a whole different shell, not Python's.  Not suitable for
beginners, to be mixing OS and Python shells too much.  Entirely
different namespaces.  Too schizo.

> Python gives us a programming language of extraordinary productivity
> at all levels of programming (especially for beginners).

I completely agree.  But we shouldn't confuse pedagogy with starting
level of sophistication.

My beginning students know as little programming as anyone, and have
bell curved abilities.  But give I fly the CP4E banner, I'm goal
directed towards a culture where the caste line between being "a
programmer" and "not a programmer" is of fading significance.

Students stream in from biology to learn enough Python to go off and
write little models, make graphs, study DNA sequencing or whatever.
That's just what biologists do, as well as squint through microscopes
and/or trap mosquitos and/or culture microbes.  This isn't about
"becoming a career programmer" at this level, it's about learning to
use a computer as one more tool of the trade.

I think the "make everything a raw_input script" philosophy harkens
back to the days when you had these people called "programmers" who
looked at source code a lot, and other people called "users" who never
did.  Pre CP4E.  A very dark age.

A huge chasm or wall separated these two psychologies, and when you
trained to become a programmer, you needed to internalize this chasm
and imagine yourself as a "dumb user" who never looks at source code
or has any awareness of namespaces.  You had to divide yourself
mentally in this way so that you'd be better able to work with the
*real* (as in actual, true to life) dumb users in the future (the
people you'd meet on the job).

I'm saying that's not the CP4E way.  We're training *you* to code for
*you* right at first, with no prehistorical "dumb users" in the
picture.  You maybe haven't committed to becoming a computer
programmer professionally.  You just want to be able to code, like any
red blooded American or Russian or Indonesian or whatever.  Like
driving a car.  Like knowing how to swim.  A basic skill.  Part of
numeracy, just like ordinary algebra, already required for a high
school degree.

You're going to become fluent in the Python environment, productive,
and we're not going to introduce you to "scripting" until a little
later, when we start to explore the sys module, including sys.args --
the infrastructure for interfacing with the OS outside of Python.

That's somewhat advanced, and that's when we get to
sys.stdin.readline() as well.  We're not just "feeding the fish" in a
Python module fish tank from the Python shell anymore, we're doing
more sysop type stuff.

Now we're more into "scripts" as in "grep through
/etc/users/myclubhouse and find out who hasn't paid dues in awhile" --
little maintenance jobs customarily executed from a terminal window,
written in Perl, Python, Ruby or whatever.  That's one use for 'em,
but it's a specialized niche, more for CS majors than biology majors.

But anyway when it comes to sysop type stuff, if there're arguments to
be passed, we usually just use POSIX switches and sys.arg
infrastructure, passing a file name if there's a ton of input to
consider.

Once again sys.stdin.readline() is a bit on the obscure side.  But
it's there, in case you need it for some reason.

Kirby