[Edu-sig] Python for non-programmers

[Kirby Urner]

>3. I said why I wanted him to know to put __init__.py in directories from
>the beginning, as a start towards developing libraries of modules as he

OK, but it's easy to just save your .py modules in the Python 
directory and move them later, adding to the search path then.  

You can do modules first, __init__.py later.  That would 
probably be my approach -- to avoid getting bogged down in
environmental nitty gritties.

>4. My assessment with Idle and PythonWin so far is that they are both too
>easy to crash and there is too much that is inscrutable.  (I haven't
>installed Idle 0.5 yet.)  More than that, I want Doug to have some short
>path of connection between what he sees in the material he creates and what
>happens operationally.  I agree that having an IDE environment is an
>improvement, once you have a sound model of the fundamental process that is
>not obscured by the tool.

This is where we disagree I guess.  I haven't found IDLE especially
crash-prone in Windows (I've used PythonWin too, but have decided 
to just use IDLE 0.5 for now).  

Sometimes, rarely, I have to ctrl-alt-delete terminate (just the 
thread, not a reboot) because I've got an infinite loop going (or, 
more likely, I'm stuck trying to compute primes up to some godawfully 
humongous number -- what I got into with Pascal's Pyramid the 
other day).

IDLE is not an IDE in the sense of "edit code, then compile/link, 
then execute" like Visual Cafe for Java or something.  It's a true 
REPL loop, a command line interpreter, exactly like what you get 
in DOS, except color coded, friendly, in a window.  The computer 
replies in blue.

>5.   I don't expect this will hurt him any, and it will teach him
>command-line use of the python processor, something that gets talked about
>in all of the books.  He can move to an IDE when he has the basic

Yes, but IDLE _is_ in interactive command line environment.  

I agree that an interactive command line should be front and 
center in the learning process.  All my prime teaching language 
candidates, Logo, Python, DrScheme, Xbase... -- have interactive 
command lines, where you can type 2+2 and get 4, or 3*"CAT" and 
get "CATCATCAT".

But the command lines I'm talking about are in the context of a
GUI.  I find that an improvement over opening a DOS or X-term
window in Windows or Linux/Unix.

>operational process under his belt.  I think he will adjust his own
>practices to suit himself once he has enough sense of what is happening.  I
>have no charge on whether he continues to run under 4DOS or do something
>else.  I think he'll keep his wheel mouse though.

You probably have a good sense of the situation in your particular 
case.  I just want to avoid the paradigm where we think "computer 
programming for everybody" means indoctrinating everyone into 
the arcana of some hopelessly geekish world.  On the contrary,
software engineers have worked very hard to transcend that world,
by devising interfaces that seem more humane.  I see no reason to
turn back the clock.

It's an ancient pitfall in the teaching process that some previous 
generation is more interested in having downliners (future 
generations) appreciate "what it was like for us in our time" 
than recognizing and responding to what's ahead:  a future that's 
alien to all of us, but is ours to own and anticipate nevertheless.

Kirby