So I'm back to helping Bernie Gunn with Python again. He's in charge of the Geokem web site, where lots of scientific information gets collated -- global data basically, much of it geochemical. The HQS is in New Zealand. I salute Bernie, a relatively old guy, for taking a flying leap to our OO paradigm, coming from a strongly procedural school of thought ala Turbo Pascal. He had it all nailed down in TP, and was producing mega amounts of good graphical data. But now he's thinking ahead, about the long term future of his site, and Python looks like a great candidate. Based on my working with Bernie, I think it's helpful to start early with the class/object distinction. He thinks in terms of graphical objects and is using Zelle's graphics.py to re-explore the world of Rectangles etc. That's a good starting point. He's starting to get that it's object.method(arguments), or noun.verb(inputs). He realizes that: rectobj = Rectangle(...) rectobj.setWidth(10) rectobj.draw() is about initializing a new object of the Rectangle class (defined in graphics.py), and using two of its methods, setWidth and draw. Except both these methods are inherited by Rectangle from GraphicsObject through _BBox. Rectangle itself only defines __init__, clone and the private _draw. OO really is a different world. I think it still makes sense to teach the subject historically, even though we *can* start with objects at the same time. In other words, have students relive some of the trauma of moving from the procedural paradigm to the object oriented one -- not to traumatize, but to give the flavor of what "paradigm" even means (including that switching between them may be difficult). Bernie is getting it, and that's testament to Python's transparent syntax (as well as to my dedication in getting my message across; because I think Bernie, and Geokem, are really cool and deserve Python's support). Kirby