Advice on giving a python course

[Harry George]

Looks ok to me.  Make sure they get to code early and often.  

I just taught a course last Thrusday and Friday.  The audience was
engineers who have been doing knowledge-based engineering with lisp
and prolog, plus accessing these apps from web sites.  Like you, I
started with 5 people and had to turn them away when we ran out of
workstations in the classroom.  

I wanted to use Essential Reference, but not all the copies arrived in
time, so mostly we worked from the web-based course notes.  On the web
page, I had links to the (locally installed) html documentation.  So
once people knew about the Library Reference, they could search for
features on their own.  I concentrated on getting people over the
hello, world barrier (getting something to run).

After the intro session and a quick scan through the remaining
sessions, the students self-selected favorite areas to work
exercises.  

Here is my outline:
    1 Introduction 
        1.1 Objectives 
        1.2 Where and why? 
        1.3 Cool Stuff 
        1.4 Setup emacs 
        1.5 Intro to documentation 
        1.6 Hello world 
        1.7 Running Hello 
        1.8 Quick Start 
        1.9 Exercise 1a 
        1.10 Exercise 1b 
        1.11 Exercise 2a 
        1.12 Exercise 2b 
        1.13 Exercise 3a 
        1.14 Exercise 3b 
        1.15 Exercise 3c
(exercises: mkpythonproj, pyperl, and regular expressions)
 
    2 CGI 
        2.1 Agenda 
        2.2 What is a CGI? 
        2.3 What is required? 
        2.4 Code faster? 
        2.5 Exercise 1a 
        2.6 Exercise 1b 
        2.7 Run faster? 
        2.8 Exercise 2 
(exercises: using cgipm.py to build, comline debug, install, and run cgi's)

    3 XML 
        3.1 Agenda 
        3.2 What is XML? 
        3.3 Why is it used? 
        3.4 How is it programmed? 
        3.5 Hello: XML file 
        3.6 Hello: DOM 
        3.7 Hello: Traverse the DOM 
        3.8 KIRTS import/export 
        3.9 Exercise 1 
        3.10 Exercise 2 

(exercises: using xml.dom for simple, then complex parse-and-write)

    4 Extend and Embed 
        4.1 Agenda 
        4.2 Extend 
        4.3 Extend -- setup 
        4.4 Extend -- code 
        4.5 Extend -- use it 
        4.6 Embed -- setup 
        4.7 Embed -- makefile 
        4.8 Embed -- code 
        4.9 Install standalone 
(exercises: extensions, embedded, and "installer")

    5 GUI 
        5.1 Agenda 
        5.2 What is required? 
        5.3 Reactive Systems 
        5.4 Model-View-Controller 
        5.5 Platform independent implementations 
        5.6 TkInter 
        5.7 Gtk 
        5.8 Exercise 1a 
        5.9 Exercise 1b 
        5.10 Exercise 1b -- cont. 
(exercises: run the Demos, pick an interesting one, see how it is
implemented, tweak it and observe changes.  I really hammered on doing
a gui-independent reactive app which could be driven by a test script
and then adding gui's.)


"Richard P. Muller" <rpm at wag.caltech.edu> writes:

> I will be giving a short course on Python to my research group
> (computational chemistry and materials science). I would like to raise
> the average level of programming ability in our group, so that more
> people can take on the "hard" programming projects that until now have
> only been undertaken by a few of the better programmers.
> 
> I had anticipated having 5-6 people show up in the group, but was
> overwhelmed with 20 people responding, which is both exciting and
> intimidating.
> 
> Since I'm sure other people on this list have taught similar courses, I
> was wondering if I could get some helpful suggestions, and/or feedback
> on the way I've structured the course.
> 
> The web page for the course is at:
> http://www.wag.caltech.edu/home/rpm/python_course/
> 
> The slides for the first lecture are at:
> http://www.wag.caltech.edu/home/rpm/python_course/Lecture_1.pdf
> 
> I wanted to give the students as much instant gratification as possible,
> which is why I introduced the Gnuplot module and NumPy in the first and
> second modules, respectively.
> 
> Any help, suggestions, criticism, or pity will be gratefully received.
> 
> Rick
> rpm at wag.caltech.edu
> 

-- 
Harry George
hgg9140 at seanet.com